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SUMMARY 


^Vhe  purpose  of  this  research  was  to  assess  the  feasibility  of 
developing  a  decision?aiding  support  system,  through  human  factors 
engineering  and  decision-making  analysis,  to  support  one  of  the  Army  Corps 
battlefield  tasks  --  mobility,  countermobility,  and  survivability  as  performed  by 
combat  engineers^  The  time  period  for  this  research  effort  was  from  09/17/87  to 
05/15/88.  ^he  research  effort  included  reviews  of  the  literature  in  the  areas  of 
use^computer  interface  design  and  technologies,  and  decision^aiding 
technologies  with  respect  to  software  techniques.  Literature  reviews  were 
augmented  by  imdepth  analysis  of  the  combat  engineer’s  decision-making 
activities.  -Specifically^  combat  engineers^stationed  at  Fort  Bragg,  North 
Carolina  (307th  Engineer  Battalion,  82nd  Airborne  Division  and  20th  Engineer 
Brigade,  XVIII  Airborne  Corps)*were  interviewed.  Based  on  these  systematic 
analysis  steps,  a  solution  was  found  which  applied  cognitive  science 
technologies  to  the  traditional  arts  of  decision  analysis,  emphasizing  the  use  of 
interactive  intelligence  as  a  modality  to  improve  combat  engineer's  decision¬ 
making  with  respect  to  developing  plans  for  engineering  operations.  A  design 
of  the  Combat  Engineer  decision-aiding  system  (CETOOLS)  to  provide 
decision-aiding  support  for  combat  engineer  planning  activities  was  developed. 
The  proposed  CETOOLS  design  was  judged  feasible  with  a  low  level  of  risk. 
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Specific  conclusions  drawn  from  the  research  and  analyses  include: 
combat  engineers  are  faced  with  a  complex  decision  situation  whereby  the 
combat  engineer  is  striving  to  support  the  operational  needs  of  the  tactical 
commander  within  the  context  of  limited  engineering  assets  and  resources  as 
well  as  time  constraints.  The  combat  engineer  must  possess  extensive 
knowledge,  experience,  and  data  to  support  tactical  mission  objectives.  An 
interactive  decision-aiding  support  system  is  warranted  to  augment  the  combat 
engineer's  decision-making  process  with  respect  to  developing  their  plans  to 
support  tactical  mission  objectives.  The  CETOOLS  system  will  consist  of  a 
multiple-analysis  architecture  that  will  utilize  a  combination  of  graphical 
techniques,  user-computer  interface  dialog  techniques,  as  well  as  statistical  and 


heuristic  techniques  whereby  the  combat  engineer  is  presented  inferences 
concerning  the  implications  concerning  their  proposed  engineer  operational 
plans  (i.e.i  estimated  manpower  resources  needed  for  specific  operations  as 
well  as  estimated  times  to  complete  such  operations).  Given  an  effective 
human-computer  interface,  the  CETOOLS  system  will  enhance  combat 
engineer's  planning  activities  by  providing  a  structure  framework  for  systematic 
evaluation  of  Mission,  Enemy,  Terrain,  Troops,  and  Time  available  factors 
(METT-T)  and  by  allowing  combat  engineers  to  transcend  the  limitations  of  their 
own  experience. 

The  CETOOLS  concept  is  potentially  applicable  in  any  decision¬ 
making  environment,  commercial  or  government,  where  plans  for  actions  are 
required  based  on  matching  complex  requirements  (objectives)  against  known 
limited  resources,  assets  and  time.  Military  applications  include  aiding  as  well 
as  training  combat  engineers  in  the  development  of  effective  operational  plans. 
Commercial  applications  include  business  decision-making  aids  for  executives, 
civil  engineers,  and  plant  production  managers  for  commercial  manufacturing. 
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1 .0  INTRODUCTION 


1.1  PHASE  I  OBJECTIVES 

This  report  was  produced  as  part  of  a  Phase  I  research  effort  awarded 
by  the  U.S.  Department  of  Defense  under  the  Small  Business  Innovation 
Research  (SBIR)  Program,  Contract  No.  DAAB07-87-C-A034,  monitored  by  the 
U.S.  Army  Communications  and  Electronics  Command  (CECOM)  at  Fort 
Monmouth,  New  Jersey. 

The  tactics  and  doctrine  of  the  modern  battlefield  have  increased  the 
complexity  and  tempo  of  modern  warfare  such  that  decision  makers  are 
required  to  make  decisions  under  less  than  optimal  conditions.  With  respect  to 
military  planning  activities,  decision  makers  must  analyze  and  synthesize 
complex  information,  formulate  plans,  evaluate  their  feasibility,  estimate  their 
potential  effectiveness,  and  then  assess  the  significance  of  all  these  factors  in 
formulating  an  optimal  plan.  All  these  activities  are  usually  conducted  under 
severe  time  constraints.  Also  compounding  the  situation  is  the  fact  that  decision 
makers  have  inherent  limitations  that  are  the  result  of  human  information¬ 
processing  shortcomings  (i.e.,  short-term  memory  limitations).  Because  of  these 
factors,  military  planners  have  recognized  the  need  for  computerized  decision- 
aids  in  order  to  alleviate  or  minimize  the  complexity  faced  by  decision  makers 
when  evaluating  situations.  The  primary  objective  of  the  Phase  I  research  was 
to  investigate  the  feasibility  of  developing  a  decision-aiding  support  system, 
through  human  factors  engineering  and  decision-making  analysis,  to  support 
one  of  the  Army  Corps  battlefield  tasks  --  mobility,  countermobility  and 
survivability  as  performed  by  combat  engineers. 
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The  original  Phase  I  proposal  outlined  four  major  tasks  to  be 


conducted: 

1. 

Select  a  decision  situation  that  will  benefit  from  some  form  of 
computerized  support  via  a  decision-aiding  support  system. 
The  direction  for  this  task  was  to  select  one  of  the  Army  Corps 
battlefield  tasks  as  the  decision  situation  which  warranted 
further  analysis. 

2.  ' 

Apply  a  methodology  that  identifies  the  decision-making  needs 
found  with  respect  to  the  selected  Army  Corps  battlefield  tasks. 
Emphasis  will  be  placed  on  identifying  the  information 
requirements  for  the  selected  decision  situation  as  well  as 
establishing  the  appropriate  technology  options  for  the  design 
and  development  of  the  decision-aiding  support  system. 

3. 

Construct  a  high  level  user-computer  interface  (UCI)  and 
functional  design  for  the  proposed  decision-aiding  support 
system. 

4. 

Document  the  Phase  1  efforts  as  well  as  develop  a  work  plan 
for  Phase  II. 

All  objectives  for  the  Phase  I  research  effort  have  been  met.  The 
concept  is  assessed  as  feasible.  This  report  presents  the  documentation  of 
these  tasks  and  forms  the  basis  for  the  positive  feasibility  assessment. 


1.2  RESULTS  OF  THE  PHASE  I  RESEARCH  EFFORT 

After  consultation  with  CECOM  personnel,  the  Army  Corps  tasks 
selected  as  being  appropriate  for  this  effort  were  those  performed  by  combat 
engineers  --  mobility,  countermobility  and  survivability.  Interviews  with 
members  of  the  Army  engineer  community  (e.g.,  US  Army  Engineer  School,  US 
Army  Engineer  Studies  Center  and  US  Army  Engineer  Topographic 
Laboratories)  further  substantiated  that  combat  engineers  are  in  need  of 
decision  aids.  The  combat  engineer  (CE)  is  faced  with  a  complex  decision 
situation  whereby  the  CE  is  constantly  striving  to  support  the  operational  needs 
of  the  tactical  commander  within  the  context  of  limited  engineering  assets  and 
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resources  as  well  as  time  constraints.  As  a  result,  the  CE  attempts  to  develop 
and  implement  a  plan  that  maximizes  the  utilization  of  his  assets  and  resources 
in  a  timely  manner.  The  CE  is  called  upon  to  make  decisions  concerning  the 
utilization  of  his  resources  and  assets  such  that  the  CE  takes  into  account  the 
Mission,  Enemy,  Terrain,  Troops,  and  Time  available  (METT-T)  To  do  so,  the 
CE  performs  several  analytic  reasoning  steps  to  derive  a  plan  that  best  supports 
the  tactical  commander's  needs. 

There  are  several  factors  that  can  disrupt  or  negatively  effect  *he 
combat  engineer’s  ability  to  derive  an  optimal  plan.  These  factors  can  be 
classified  as  either  external/task  situation  factors  or  internal  human 
abilities/cognitive  processing  factors.  External/task  situation  factors  are: 

•  Complexity  and  dynamics  of  battlefield  operations  that  warrant 
combat  engineering  support, 

•  Lack  of  computer  support  for  information  requirements  and 
computationai  support  for  estimates  concerning  CE  operations, 

•  Volume  and  complexity  of  information  to  be  assessed, 

•  Need  to  make  decisions  in  the  absence  of  information,  and 

•  External  time  constraints  imposed  on  the  CE  for  decision 
making. 

Internal  human  abilities/cognitive  processing  factors  include: 


Experience  level  (knowledge)  of  the  CE, 

Inherent  human  information-processing  and  high-level 
cognitive  reasoning  limitations,  and 

Complexity  of  reasoning  steps  involved  in  making  decisions 
concerning  combat  engineering  plans. 
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All  these  factors  (external  and  internal)  can  impact  negatively  or 
interact  with  each  other  adversely  such  that  the  CE  is  at  a  disadvantage  in 
deriving  an  optimal  plan.  The  goal  of -this  research  effort  was  to  assess  the 
relative  significance  of  these  factors  and  to  identify  the  features  that  were 
needed  for  a  decision-aiding  support  system  that  would  minimize  the  impact  of 
such  factors. 

In  order  to  fully  understand  the  impact  of  the  above  mentioned  factors, 
interviews  were  conducted  with  combat  engineers  in  operational  settings.  This 
was  an  extremely  important  step  in  our  research  effort.  Unlike  typical  computer 
systems  in  a  military  setting  that  are  designed  to  satisfy  doctrinal  or  tactical 
requirements,  decision-aiding  support  systems  are  designed  to  satisfy  user 
requirements  that  can  only  be  derived  by  user  involvement  early  in  the  system 
development  process.  We  conducted  interviews  with  combat  engineers 
stationed  at  Fort  Bragg,  North  Carolina  (307th  Engineer  Battalion,  82nd 
Airborne  Division  and  20th  Engineer  Brigade,  XVIII  Airborne  Corps).  The 
combat  engineers  at  Fort  Bragg  were  selected  because  they  represent 
engineers  who  are  working  under  severe  time  constraints  as  well  as  under 
imposed  limitations  with  respect  to  equipment  and  personnel  available  'or  any 
combat  operation.  Understanding  their  decision-making  needs  during  their 
planning  process  was  seen  to  typify  the  needs  that  any  combat  engineer  may 
have,  especially  during  actual  combat  operations  when  time,  assets,  and 
resources  will  be  in  short  supply.  Results  from  these  interviews  indicated  that 
combat  engineers  need  a  decision-aidinn  support  system  that  not  only  provides 
software  support  for  their  decision-ma'  .iig  planning  process  but  also  provides  a 
"user-friendly"  interface. 

These  two  important  decision-aiding  design  concepts  ("user- 
friendliness"  and  software  intelligence)  provided  the  focus  for  the  efforts 
described  in  this  report.  Such  findings  were  further  supported  by  a  detailed 
analysis  of  the  decision-making  process  that  the  combat  engineers  of  307th 
Engineer  Battalion,  82nd  Airborne  Division  perform  to  develop  their  plans.  As  a 
result  of  this  front-end  analysis,  subsequent  efforts  for  this  Phase  I  project 
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concentrated  on  an  investigation  of  the  software  techniques  and  UCI 
technologies  applicable  for  addressing  combat  engineer’s  needs.  The 
proposed  Combat  Engineer  decision-aiding  system  (CETOOLS)  will  utilize 
current  human-computer  dialogue  techniques  (i.e.,  windowing),  information 
display  concepts  (i.e.,  graphics)  and  software  techniques  (i.e.,  expert  system 
technologies)  to  maximize  the  utility  that  such  a  system  has  to  offer.  As  with  any 
decision-aiding  support  system,  CETOOLS  will  require  an  iterative  design 
approach  during  its  developmental  cycle  (Phase  II  efforts)  to  ensure  it  meets  the 
needs  of  combat  engineers.  This  is  especially  important  as  combat  engineer’s 
requirements  change  depending  upon  the  mission  (i.e.,  offensive  or  defensive 
support  requirements). 

The  following  steps  served  as  the  approach  to  determining  the 
feasibility  of  CETOOLS: 

1.  Review  relevant  decision-aiding  technology  with  respect  to 
software  techniques  (i.e.,  choice  models). 

2.  Review  relevant  human  factors  engineering  literature  to 
determine  relevant  techniques  for  the  user-computer  interface 
and  dialog  interactions. 

3.  Specify  system  functionality  for  CETOOLS,  including  what  the 
system  will  do  for  the  user,  what  the  system  will  demand  of  the 
user,  and  how  the  system  will  look  to  the  user. 

4.  Evaluate  the  feasibility  of  constructing  a  system  as  described, 
taking  into  account  such  factors  as  current  technology, 
cost/benefit  trade-offs,  etc. 

5.  Develop  a  preliminary  design  for  the  Phase  II  prototype  effort. 

1.3  EUTUBE  APPLICATIONS  OF  THE  CETOOLS  SYSTEM 

The  development  of  the  CETOOLS  system  will  assist  combat 
engineers  in  developing  their  plans  to  support  tactical  commanders.  That  is, 
CETOOLS  will  provide  software  support  such  that  adequate  consideration  will 
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be  possible  concerning  the  factors  (e.g.,  time,  resources,  assets,  etc.)  that  can 
impact  the  feasibility  and  success  of  any  proposed  plan.  Also,  the  system  will 
allow  combat  engineers  to  generate  alternative  plans  which  otherwise  would 
not  be  possible  because  of  time  constraints.  As  a  result  of  this  system 
capability,  combat  engineers  will  gain  valuable  experience  in  analyzing 
situations  in  a  more  flexible  and  responsive  manner.  This  experience  will  be 
important  for  actual  combat  situations  where  changing  operational 
requirements  will,  no  doubt,  be  the  norm  and  not  the  exception  and  will  require 
a  flexible  approach  by  combat  engineers.  This  will  be  especially  significant  for 
inexperienced  combat  engineers  who  could  be  easily  overwhelmed  by  the 
complexity  of  a  battlefield  situation.  The  uses  of  the  proposed  system  are  not 
limited  to  operational  planning.  CETOOLS  will  also  provide  an  excellent 
training  vehicle  for  junior  leaders  during  field  training  exercises,  command  post 
exercises,  and  emergency  deployment  readiness  exercises.  The  system  will 
offer  the  ability  to  view  operational  situations  (i.e.,  miss  requirements)  via 
software  such  that  war  game  type  scenarios  could  be  used  with  CETOOLS  for 
training  purposes.  As  a  result,  combat  engineers  will  gain  valuable  experience 
which  otherwise  would  require  on-the-job  training.  An  added  benefit  will  be  to 
relieve  the  commander  and  staff  of  administrative  burdens  by  automating  such 
functions  as  the  Unit  Status  Report,  vehicle  maintenance  records,  load  plans, 
and  training  schedules. 


1.4  REPORT  OVERVIEW 

This  report  is  organized  as  follows: 


Section  2  presents  the  overall  technical  approach  used  to 
develop  the  CETOOLS  system. 

Section  3  presents  an  overview  of  the  combat  engineer 
working  environment  as  exemplified  by  the  82nd  Airborne 
Division. 

Section  4  presents  a  detailed  analysis  of  the  combat  engineer 
decision  making  process  as  exemplified  by  the  82nd  Airborne 
Division. 
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Section  5  presents  a  review  of  decision-aiding  technologies 
relevant  for  the  CETOOLS  system. 

Section  6  provides  a  review  of  technologies  relevant  to  the 
CETOOLS  user  interface. 

Section  7  presents  the  preliminary  design  of  the  CETOOLS 
system. 

Section  8  presents  an  assessment  of  the  proposed  system’s 
feasibility,  including  risk  areas,  and  provides  a  description  of 
the  goals  and  objectives  of  a  Phase  II  program  to  develop  the. 
CETOOLS  system. 

Appendix  A  presents  a  historical  overview  of  countermobility 
principles  that  combat  engineers  must  consider  when 
developing  their  plans. 

Appendix  B  presents  the  proposed  components  for  the  user- 
computer  interface  (UCI)  for  the  CETOOLS  system.  This 
includes  input  devices  (i.e.,  mouse),  screen  layout,  and 
dialogue  components  (i.e.,  windows). 
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2.0  TECHNICAL  APPROACH 


The  technical  approach  described  in  this  section  is  based  on  a 
methodology  developed  by  Analytics  that  has  been  successfully  demonstrated 
in  numerous  tactical  situations  (e.g.,  Zaklad,  et  al.,  1986;  Zachary,  et  a!.,  1982). 


Combat  Engineers  (CE)  typically  base  their  inferences  concerning 
needed  assets  and  resources  to  support  mission  objectives  on  somewhat 
intuitive  reasoning.  In  many  cases,  the  combat  engineer  intuitively  recognizes 
that  a  given  task  will  result  in  a  given  expenditure  of  resources  such  as 
manpower  and  equipment.  Experienced  CE's  tend  to  develop  intuitive  models 
based  on  previous  experience  in  evaluating  mission  objectives  and  inferring 
possible  CE  actions.  Therefore,  the  primary  objective  for  the  Phase  I  effort  is  to 
define  a  consistent  framework  for  evaluating  CE  actions  and  inferences 
concerning  resource  and  asset  requirements  and  to  conceptualize  the  features 
of  a  decision-aiding  support  system  that  captures  these  reasoning  steps. 
Specifically,  the  direction  of  the  Phase  I  research  is  to  identify  the  technologies 
(e.g.,  Al  technologies,  decision-aiding  techniques,  etc.)  that  are  relevant  to  the 
CE's  task  and  determine  what  role  the  relevant  technologies  should  play  in  the 
development  of  a  decision-aiding  support  system  to  assist  CE's  in  their  decision 
functions. 


2.1  CONCEPT  DEEINITIPN 

The  innovative  approach  taken  to  enhance  CE  decision-making  is  to 
develop  a  decision-aiding  support  system  that  is  based  upon  human  factors 
engineering,  artificial  intelligence,  user-computer  interface  technologies,  and 
expert  system  technology.  This  system  will  be  referred  to  as  the  Combat 
Engineer  decision-aiding  support  system  --  CETOOLS. 
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2.2  CETOOLS  SYSTEM:  HIGH-LEVEL  DESIGN  GOALS 

The  establishment  of  high-level  design  goals  for  CETOOLS  is  the  first 
step  in  ensuring  the  development  of  a  practical  and  functional  system.  These 
design  goals  include  the  development  of  a  user  "friendly"  system  as  well  as  a 
system  architecture  flexible  enough  to  meet  the  future  needs  and  the  changing 
scope  of  CE  functions.  Ease  of  programming  and  maintenance  will  also  be  a 
major  goal  of  the  design.  A  top-down  analysis,  as  illustrated  in  Figure  2-1 ,  was 
performed  as  part  of  the  high-level  design  goal  process  which  focused  on: 

•  Defining  user  needs  and  requirements, 

•  Allocating  functions  between  the  user  and  CETOOLS, 

•  Evaluating  user-computer  interface  options, 

•  Defining  a  software  development  approach,  and 

•  Defining  the  requisite  software  and  hardware  environment. 

The  system  considerations  and  research  for  each  of  these  areas  are 
described  in  this  section. 


2.3  USER  NEEDS  AND  REQUIREMENTS 

The  first  step  in  developing  any  system  is  to  identify  user  needs  and 
requirements  to  be  incorporated  into  the  proposed  system.  To  do  so  for  the  CE 
entails  a  multi-faceted  front-end  analysis  approach.  This  front-end  analysis 
approach  consists  of: 

*  Description  of  the  user  population  of  CE's  (user  profile)  such 
that  the  skills  and  knowledge  of  the  intended  users  are 
identified, 

•  Description  of  the  external  environment  that  the  CE  must  work 
in  and  its  effects  on  the  decision  making  process  for  the  CE, 
and 
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Figure  2-1.  CETOOLS  Technical  Approach 


•  Description  of  the  internal  decision  making  processes  that  the 
CE  goes  through  to  arrive  at  an  assessment  of  asset  and 
resource  requirements  to  meet  mission  objectives. 

2.3.1  User  Profile 

The  CETOOLS  users  will  probably  represent  a  cross  section  of 
computer  experience  from  novices  with  minimal  experience  in  using  computers 
to  sophisticated  users.  In  addition,  CETOOLS  users  may  possess  varying 
levels  of  skills  for  the  CE  function.  Therefore,  the  user  interface  must  be  "user- 
friendly",  require  minimal  computer  knowledge,  promote  rapid  learning  of 
CETOOLS,  and  provide  the  flexibility  to  solve  a  wide  range  of  problems. 
CETOOLS  will  require  extensive  dialogue  with  the  user  in  order  to  characterize 
their  problem.  In  addition,  CETOOLS  will  require  sophisticated  techniques  to 
guide  and  direct  the  user  in  this  process.  Finally,  the  needs  of  the  novice  must 
be  balanced  against  the  needs  of  a  more  experienced  user  in  developing  the 
user-computer  interface. 


2.3.2  Decision  Making  Analysis 

The  CETOOLS  system  will  assist  the  CE  in  developing  more  accurate 
inferences  about  the  assets  and  resources  needed  for  future  CE  operations. 
Current  estimates  are  presently  developed  based  upon  the  CE’s  intuition,  upon 
informal  comparisons  with  previous  work  (past  experiences),  or  manual  labor 
intensive  computation.  To  determine  the  nature  and  type  of  decision  making 
assistance  needed  by  the  CE,  a  detailed  analysis  was  conducted  of  the  CE’s 
decision  making  environment.  Section  3  describes  the  CE's  functions  and  the 
external  environment  that  the  CE  works  in  and  its  effects  on  the  decision  making 
process  for  the  CE.  Section  4  describes  the  internal  decision  making  processes 
that  the  CE  goes  through  to  arrive  at  an  assessment  of  assets  and  resources  for 
future  actions.  For  both  Sections  3  and  4,  the  307th  Engineer  Battalion,  82nd 
Airborne  Division,  served  as  the  basis  for  these  analyses. 
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2.4  ALLQCAI3QILQELE1JNQTIQNS 

The  functional  allocation  step  is  necessary  to  determine  what  system 
functions  should  be  distributed  between  the  user  and  CETOOLS.  Computer 
support  is  warranted  in  those  circumstances  where  users  have  difficulty  in 
performing  some  functions  because  of  limitations  in  human  information¬ 
processing  capabilities  (e.g.,  complex  quantitative  calculations).  Therefore, 
functional  allocation  between  the  user  and  the  system  will  be  dictated  according 
to  the  functional  requirements  needed  to  analyze  and  evaluate  situations. 

In  accordance  with  the  goal  of  a  high-level,  user-oriented  interface,  as 
many  ancillary  functions  as  possible  will  be  allocated  to  CETOOLS.  These 
include  user  aids  such  as  menu-driven  interface;  on-line  guidance  via  a  HELP 
capability;  an  explanation  facility  to  assist  in  the  interpretation  of  results;  and 
detailed  and  easily  understood  error  messages  and  recovery  procedures. 

It  is  also  clear  that  the  human  is  essential  to  the  CE  function  and  that 
any  automation  must  be  designed  to  be  a  tool  to  assist  the  CE  but  not  to 
supplant  the  CE.  Most  successful  knowledge-based  tools  have  been 
developed  as  tools  to  assist  but  not  to  replace  human  decision-makers. 

2.5  USER  INTERFACE  APPROACH 

Since  CETOOLS  will  be  a  complex  system,  the  design  of  the 
CETOOLS  user-computer  interface  (UCl)  will  be  an  important  determinant  of 
successful  system  operation  and  effective  performance.  The  UCl  will  be 
designed  to  take  advantage  of  the  most  recent  advances  in  human  factors 
engineering,  artificial  intelligence,  and  advanced  display  technologies.  A 
primary  design  goal  is  the  development  of  a  system  which  has  maximum 
flexibility  and  is  adaptable  to  new  applications  (e.g.,  Digital  Topographic 
Support  System  -  DTSS)  and  which  is  highly  usable  in  terms  of  both 
operation/execution  and  analysis  of  results.  The  design  of  the  UCl  must  be 
considered  during  every  phase  of  the  development  of  CETOOLS  to  ensure  that 
CETOOLS  incorporates  high  degrees  of  flexibility,  adaptability,  consistency, 
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and  responsiveness  with  regard  to  the  way  in  which  the  user  will  interact  with  all 
the  components  of  CETOOLS.  It  is  essential  to  integrate  human  factors  into  the 
early  stages  of  the  design  process  where  it  can  have  the  greatest  benefit.  An 
efficient  user  interface  design  may  cost  more  in  terms  of  time  and  money  to 
implement,  but  it  may  also  result  in  significant  benefits  during  the  system's 
productive  life.  Non-productive  training  time  can  be  reduced;  user 
misunderstandings  leading  to  interpretation  errors  can  be  avoided;  and  user 
satisfaction  can  be  dramatically  increased. 


The  development  of  the  user  interface  will  be  based  upon  analysis  of 
the  following: 


Interactive  dialogue  analysis  —  establishing  dialogue 
style  (e.g.,  menu,  command,  graphics,  etc.),  user  response, 
data  entry  screen  design,  on-line  help,  error  message  design, 
and  color  coding. 

Input  device  and  techniques  analysis  —  examining 
properties  of  available  input  devices  (e.g.,  keyboard,  mouse, 
graphic  tablet  etc.)  and  their  interaction  with  the  dialogue. 

Output  requirements  analysis  —  examining  properties  of 
available  output  devices  and  information  to  be  conveyed  (e.g, 
text,  graphics). 


Another  design  goal  is  that  the  user  interface  should  be  consistent 
across  all  components  of  the  CETOOLS  system.  Other  principles  that  have 
been  identified  in  the  human  factors  literature  as  critical  to  successful  user 
interfaces  include  the  following: 

•  "Friendly"  dialogues  and  error  handling, 

•  On-line  help  routines, 

•  Meaningful  feedback  provided  to  avoid  confusion, 

•  Minimal  strain  on  human  memory  capacity, 

•  Simplicity  rather  than  complexity,  and 
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Demands  tailored  to  the  user’s  skill  levels. 


Wherever  possible,  the  design  of  the  user  interface  will  be  in  accordance  with 
established  human  factors  guidelines  and  standards. 

Section  6  describes  the  technologies  that  were  considered  for  the 
development  of  an  effective  CETOOLS  user-computer  interface. 


2.6  DEVELOPMENT  APPROACH 

Traditional  software  development  approaches  assume  that  all  system 
requirements  can  be  precisely  determined  and  specified  in  detail  prior  to  any 
contextual  design,  implementation,  or  operational  experience.  The  design 
specifications  are  frozen  at  some  point  and  the  entire  system  is  based  upon 
these  specifications.  By  contrast,  the  prototype  approach  assumes  that  precise 
requirements  are  not  always  pre-definable  so  the  system  is  developed  utilizing 
a  building  block  approach.  A  building  block  approach  to  system  development 
establishes  the  working  foundation  of  a  system  quickly  and  in  such  a  manner 
that  it  can  be  gradually  expanded  one  step  at  a  time.  The  premise  of 
prototyping  is  that  it  is  easier  and  quicker  to  modify  and  improve  a  tangible 
system  than  to  draw  up  specifications  for  a  system  that  can  handle  every 
conceivable  requirement.  This  is  particularly  true  for  expert  and  knowledge 
based  systems  where  an  iterative  approach  is  required  to  establish  and  refine 
the  knowledge  base.  Several  studies  have  indicated  that  a  prototype  approach 
significantly  improves  the  probability  that  a  useful  system  will  be  developed  and 
that  the  overall  development  cycle  will  be  shortened  (Mason  and  Carey,  1983). 
Additional  experimental  results  suggest  that  prototyping  increases  the  actual 
utilization  of  a  system  by  the  user,  and  system  performance  was  rated  higher  by 
users  of  prototyped  systems  than  by  users  of  systems  developed  using 
traditional  approaches  as  measured  in  terms  of  user  satisfaction  with  the  system 
and  its  perceived  accuracy,  utility,  and  functionality  (Alavi,  1984). 

Prototyping  begins  in  the  analysis  phase  of  system  development  with 
a  first  prototype  based  on  a  high-level  functional  analysis.  It  does  not  include 
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every  feature  the  eventual  system  might  include,  but  at  each  stage  implements 
the  desired  goals  effectively  with  minimal  development  costs.  The  prototyping 
approach,  illustrated  in  Figure  2-2,  consists  of  the  following  steps: 

1.  Specify  Prototype  Goals  —  clearly  identify  the  scope  of  the 
prototype  and  determine  how  it  is  to  be  evaluated. 

2.  Develop  Prototype  —  design  and  implement  prototype; 
determine  what  functional  modules  must  be  developed  and 
how  they  will  be  integrated  with  modules  in  the  current 
operational  version. 

3.  Use  and  Evaluate  Prototype  —  demonstrate  the  prototype 
to  the  user  in  the  context  of  actual  applications  and  elicit 
feedback  from  the  users  in  terms  of  how  the  prototype  meets 
their  needs  and  requirements. 

4.  Implement  Required  Modifications  —  incorporate  any 
indicated  modifications  into  the  prototype  and  repeat  the 
evaluation  process. 

When  a  particular  prototype  is  functioning  satisfactorily,  it  is  made 
available  to  the  user  for  evaluation  to  determine  if  the  system  development  is  on 
the  right  track  and  performs  as  expected  and/or  required.  Users  can 
knowledgeably  suggest  changes  that  will  improve  the  system  and  make  it  more 
applicable  to  their  needs.  The  system  developers  can  then  incorporate  those 
changes  with  a  clear  understanding  of  what  exactly  needs  to  be  changed  and 
how  it  should  look  when  completed.  Each  succeeding  version  of  the  prototype 
more  accurately  reflects  the  users'  requirements  and  incorporates  more  of  the 
features  of  the  eventual  system.  The  prototyping  process  is  reiterated  until  all 
system  goals  have  been  developed  and  evaluated. 

The  traditional  approach  to  software  development  is  best  suited  for 
systems  with  simple  and  static  requirements.  But  for  dynamic  and  complex 
systems,  the  best  way  to  develop  the  system  is  with  a  prototyping  approach. 
The  user's  understanding  of  a  system  is  an  evolutionary  process.  Changes  of 
meaning  and  structure  of  the  system  reflect  the  learning  process  and  growth 
that  accompany  every  application  experience.  In  order  to  increase  the  usability 
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of  the  system,  it  is  necessary'  to  accommodate  these  changes,  not  to  impede 
them.  An  approach  that  exposes  the  user  to  realistic  versions  of  the  final 
application  will  iead  to  wide  exploration  cf  the  application  alternatives  during 
the  earliest  stage  of  development. 


2.7  SOFTWARE  AND  HARDWARE  ENVIRONMENT 

A  critical  aspect  of  the  CETOOLS  system  is  defining  the  appropriate 
computer  environment  to  be  used  for  the  system  that  is  conducive  for  both 
system  development  and  actual  CE  usage.  In  order  to  provide  an  "intelligent" 
user-computer  interface  to  the  CETOOLS  system,  it  is  appropriate  that 
CETOOLS  reside  on  a  hardware  configuration  that  provides  a  self-contained, 
intelligent  workstation.  The  advantage  to  this  configuration  is  the  flexibility  one 
has  in  developing  a  UCI  without  the  constraints  imposed  by  mainframe  type 
systems  that  offer  few  UCI  options.  The  highly  visual  and  "friendly"  user 
interface  to  be  developed  for  CETOOLS  requires  high-resolution  bit-mapped 
graphics,  color  monitor,  and  a  pointing  device  such  as  a  mouse.  Bit-mapped 
graphics  permit  the  rapid  display  of  graphic  information.  Since  effective  use  of 
color  can  improve  the  user's  performance,  a  color  monitor  is  recommended.  A 
mouse  is  a  pointing  device  that  will  allow  the  CETOOLS  user  to  spatially 
manipulate  information  and  select  commands  or  locations  on  the  screen  without 
having  to  learn  specialized  interface  commands. 
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3.0  COMBAT  ENGINEER  ENVIRONMENT 


3.1  INTRODUCTION 

The  combat  engineer's  primary  role  is  to  provide  engineering  support 
that  ensures  that  the  tactical  commander’s  mission  plans  are  successfully 
implemented.  To  understand  how  the  combat  engineer  proceeds  in  developing 
his  plans,  it  is  important  to  understand  the  working  and  organizational 
environment  in  which  the  CE  is  a  member.  By  so  doing,  one  can  identify  the 
important  environmental  and  organizational  factors  that  the  CE  must  consider 
when  developing  his  plans.  In  addition,  these  environmental  and 
organizational  factors  must  be  considered  in  the  design  of  the  proposed 
CETOOLS  system  such  that  CETOOLS  offers  assistance  to  the  combat 
engineer  that  complements  the  organizational  flow  of  information  and  decision¬ 
making. 


What  follows  is  a  description  of  the  82nd  Airborne  Division 
operational  environment  which  illustrates  the  complex  and  fast  moving 
environment  in  which  the  CE  decision  maker  must  operate.  Although  the  82nd 
Airborne  environment  possesses  unique  features,  it  exhibits  many  of  the 
characteristics,  such  as  time  constraints  and  logistical  problems,  that  all  combat 
engineers  will  face  on  the  modern  battlefield. 


3.2  82ND  AIRBORNE  DIVISION  OPERATIONAL  ENVIRONMENT 

The  82nd  Airborne  division  is  the  cornerstone  of  the  Army's 
commitment  to  the  Rapid  Deployment  Force.  It  has  the  unique  capability  to 
begin  deployment  on  as  little  as  eighteen  hours  notice.  This  significant 
capability  to  rapidly  project  a  powerful  ground  force  to  trouble  spots  anywhere 
in  the  world  provides  national  decision  makers  with  a  range  of  options  that  no 
other  force  can  offer.  As  recent  world  events  have  shown,  the  introduction  of 
airborne  forces  provide  a  powerful  deterrent  to  a  would-be  aggressor.  When 
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deterrence  fails  or  events  move  rapidly  out  of  control,  airborne  forces  can  be 
used  to  achieve  strategic  and  tactical  surprise  by  delivering  a  strong  first  blow. 
Additionally,  the  division  has  the  capability  to  conduct  sustained  ground 
operations  when  augmented  by  additional  support  units.  Past  employment  of 
the  82nd  Airborne  includes: 

•  A  Hshow  of  force",  Honduras,  1988, 

•  Evacuation  of  US  nationals,  Grenada,  1983, 

•  Peacekeeping,  Egypt,  1981, 

•  Rapid  reinforcement,  Vietnam,  1968, 

•  Stabilization  operations,  Haiti,  1965,  and 

•  Sustained  operations,  Europe,  1943-1945. 

3.3  COMPOSITION 

The  82nd  Airborne  closely  resembles  a  conventional  infantry  division 
in  its  composition.  It  is  composed  of  nine  airborne  infantry  battalions  organized 
into  three  brigades  supported  by  an  artillery  brigade,  an  armor  battalion,  and  a 
number  of  combat  support  and  combat  service  support  units. 


This  organization,  however,  is  somewhat  misleading.  The  82nd 
Airborne,  like  other  divisions,  seeks  to  optimize  its  combat  forces  by  creating  a 
task  force  that  combines  all  of  the  facets  of  the  division  into  a  cohesive  whole.  A 
division  cannot  operate  by  employing  its  units  separately.  Were  it  to  do  so,  it 
could  only  bring  a  fraction  of  its  combat  power  to  bear.  In  order  to  effectively 
move,  shoot,  and  communicate,  the  total  combined  arms  and  services  of  the 
division  must  function  as  a  team.  This  concept  of  operations  is  mirrored  at  every 
echelon  using  the  airborne  infantry  unit  as  a  planning  centerpiece.  Figure  3-1 
illustrates  how  one  infantry  brigade  is  supported  by  other  divisional  assets. 
Similarly,  each  of  these  supporting  assets  is  further  subdivided  to  directly 


3-2 


Figure  3-1 .  Infantry  Brigade  Task  Force 
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support  each  of  the  brigades  subordinate  battalions.  As  a  result,  the  82nd  can 
more  accurately  be  viewed  as  being  composed  of  three  brigade  task  forces  with 
each  brigade  task  force  composed  of  three  battalion  task  forces. 

To  facilitate  planning  and  training,  the  82nd  operates  in  garrison  on  a 
rotating  basis.  There  are  three  six  week  cycles  through  which  the  brigades 
rotate.  During  the  "mission"  cycle,  one  brigade  will  assume  the  role  of  the 
"Division  Ready  Brigade"  and  its  subordinate  battalions  will  be  in  high  state  of 
readiness.  The  other  brigades  will  be  involved  in  either  the  "intensive  training 
cycle"  or  the  "support  cycle."  Regardless  of  which  cycle  the  brigade  is  in,  each 
of  the  division's  nine  battalions  is  denoted  by  a  number  which  indicates  its 
availability  for  deployment.  In  the  division  ready  force,  the  battalions  will  be 
designated  as  the  "Division  Ready  Force  (DRF  1 ,  the  DRF  2  and  the  DRF  3.  The 
brigade  involved  in  the  intensive  training  cycle  will  consist  of  the  DRF4,  DRF  5, 
and  the  DRF  6.  The  brigade  in  the  support  cycle  will  consist  of  the  DRF7,  DRF 
8,  and  DRF  9.  At  the  end  of  each  six  week  cycle,  the  brigades  rotate 
responsibilities  and  their  subordinate  battalions  will  increase  or  decrease  their 
level  of  readiness  accordingly.  The  DRF  1  can  be  fully  assembled  in  less  than 
two  hours  time  and  will  be  the  first  unit  to  depart  Fort  Bragg  within  eighteen 
hours  of  an  alert.  The  entire  brigade  task  force,  referred  to  as  the  Division 
Ready  Brigade  (DRB)  during  mission  cycle,  can  be  fully  assembled  in  less  than 
six  hours. 


A  further  refinement  on  the  task  organization  concept  are  generic 
"force  packages."  These  force  packages  are  troop  and  equipment  lists  which 
facilitate  contingency  planning  for  six  specific  types  of  missions.  Force 
packages  are  intended  to  serve  as  a  planning  baseline  to  assist  in  rapidly 
tailoring  forces  to  the  specific  mission.  The  six  force  packages  are  designed  not 
with  a  specific  mission  in  mind,  but  rather  by  the  size  of  the  force  the 
commander  estimates  it  will  take  to  accomplish  the  mission.  The  developed 
force  packages  are: 

1 .  Airfield  seizure  —  Light, 
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2.  Airfield  seizure  —  Medium, 

3.  DRB  —  Light, 

4.  DRB  —  Medium, 

5.  Division  —  Light,  and 

6.  Division  —  Medium. 


Table  3-1  illustrates  a  portion  of  a  Division  Ready  Brigade's  (DRB)  Medium 
Force  Package  with  respect  to  personnel  and  equipment  for  Brigade 
Headquarters,  an  Infrantry  Battalion  and  an  Engineer  Support  Company. 
Should  it  be  necessary  to  augment  any  of  the  above  packages,  a  series  of 
Incremental  Force  Packages  also  exist  to  provide  specialized  support  to  the 
deploying  force.  The  modularity  of  the  82nd  force  structure  and  tactical  doctrine 
allows  for  diverse  units  to  be  molded  together  on  very  short  notice,  develop  a 
comprehensive  plan  considering  all  elements  of  combat  power,  quickly  deploy 
to  the  objective  area,  and  accomplish  the  mission. 

3-4  AIRBORNE  OPERATIONS 

As  described  above,  airborne  forces  provide  national  decision 
makers  with  a  unique  capability  to  project  military  force.  This  unique  capability 
is  accompanied  by  unique  planning  considerations  and  limitations.  It  should  be 
noted  that  the  82nd  is  capable  of  performing  two  types  of  airborne  operations  — 
each  with  its  own  advantages  and  disadvantages.  The  first  is  an  airdrop 
operation  in  which  personnel  and  equipment  are  delivered  to  the  objective  by 
parachute.  Airdrop  operations  are  normaily  used  when  the  objective  is  in  a 
contested  area  and  the  division  has  no  alternative  but  to  make  a  forced  entry. 
Airdrop  operations  have  the  advantage  of  achieving  strategic  and  tactical 
surprise  at  the  objective  area.  The  disadvantage  of  airdrop  operations  is  that 
they  are  difficult  to  plan,  conduct,  and  place  severe  limitations  on  the  number 
and  type  of  forces  that  can  be  delivered  to  the  objective. 
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TABLE  3-1  Illustration  of  Division  Ready  Brigade's  Medium  Force  Package 


UNIT 

PAX 

PER  UNIT 
DROP  A/L 

NO  OF 
UNITS 

A-ECHELON 
(HVY  DRP) 

B-ECHELON 

(AIRLAND1 

DRB  ONE 

Bde  HQs 

22 

5 

1 

3-M998 

3-M998 

1-M998  (ADA) 

-USAFLNO 

2 

0 

1 

1-M998 

-  USAF  TACP 

2 

0 

1 

1-M998 

-  Bde  FSO  TM 

4 

0 

1 

1-M998 

INFANTRY 

BATTALION 

3 

Bn  HQs 

28 

2 

3 

1-M998 

1-M998 

Medical  Pit 

18 

2 

3 

2-M996 

2-M996 

Commo  Pit 

8 

2 

3 

1-M998 

Support  Pit 

8 

2 

3 

1 -M35  w/wtr  trl 

Scout  Pit 

18 

0 

3 

5-Motor  cycles 

81mm  Mort  Pit 

16 

4 

3 

2-M998 

1-M998 

Bn  FSO  Tm 

4 

0 

3 

1-M998 

gNQINEEB 

ENG  CO  (-) 

97 

4 

1 

1-M998 

1 -Dozer 

1-5T  Dump  Trk 

1  -1  ST  Tilt  Trl 

-LARP 

1 

1-Loader  1-2  1/2T  Dump  Trk 

1-13  Wheel  Roller 

1 -Grader  1 -Air  Compressor 
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Airland  operations  refer  to  the  delivery  of  troops  and  equipment  to 
the  objective  area  by  landing  at  a  secure  airfield.  The  obvious  advantages  are 
that  units  arrive  in  an  organized  fashion  as  opposed  to  having  to  reassemble  on 
the  drop  zone,  more  equipment  can  be  delivered  quickly  and  is  immediately 
ready  upon  arrival.  The  disadvantage  is  that  using  a  secure  airfield  may  in 
some  cases  signal  the  friendly  force's  intention  to  the  enemy. 


Wherever  possible,  airland  operations  will  be  the  preferred  option. 
For  planning  purposes,  however,  the  82nd  normally  assumes  a  "worst  case" 
scenario  and  plans  to  secure  a  contested  airhead.  In  many  instances,  the 
commander  will  choose  to  employ  a  combination  of  both  options  by  using  part 
of  his  force  to  seize  and  secure  an  airfield  by  airdrop  and  deliver  the  rest  of  the 
force  by  the  airland  technique. 

In  either  case,  the  personnel  and  equipment  of  an  airborne  force 
should  be  delivered  to  the  objective  area  in  the  shortest  time  available.  The 
faster  the  troops  and  their  equipment  and  supplies  are  on  the  ground,  the  faster 
they  can  develop  combat  power  to  secure  the  objective  and  defend  the  airhead. 

3.5  MISSION  PLANNING 

As  with  other  US  forces,  the  order  to  deploy  the  82nd  will  normally  be 
initiated  by  the  Joint  Chiefs  of  Staff.  As  illustrated  in  Figure  3-2,  this  order  will 
then  be  directed  to  the  responsible  theater  command.  The  82nd  is  unique  in 
that  is  supports  the  contingency  planning  of  five  theater  commands.  The  theater 
command  will  then  direct  the  order  to  the  18th  Airborne  Corps  which  is 
composed  of  the  82nd,  the  101st  Airborne  Division  (Air  Assault),  and  the  24th 
Infantry  Division  (mechanized).  When  the  deployment  of  Corps  forces  is 
imminent,  but  not  yet  ordered,  the  Corps  will  initiate  a  planning  sequence 
known  as  the  X-Hour  sequence.  This  ensures  that  should  the  order  to  deploy 
come,  all  staff  sections  will  be  prepared  to  directly  support  operations.  If  the 
Corps  Commander  chooses  the  82nd  for  the  mission,  he  will  initiate  what  is 
known  as  the  "N  -  Hour  sequence."  This  sequence  alerts  the  division  that  a 
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Figure  3-2.  Mission  Planning 


deployment  is  planned  and  puts  in  motion  a  complicated  series  of  events 
designed  to  ensure  that  the  first  battalion  task  force  is  departing  Fort  Bragg  a 
minimum  of  eighteen  hours  later. 

N  -  Hour  is  the  term  used  to  refer  to  the  time  the  division  is  notified  or 
alerted.  Two  hours  later,  N  +  2,  the  division  commander  and  staff  will  brief  the 
DRB  and  DRF  on  the  mission.  The  DRB  and  DRF  commanders  will  then  begin 
their  planning.  Although  the  higher  echelon  will  always  support  the  lower 
echelon,  the  DRB  and  DRF  planning  process  will  be  inextricably  linked.  For 
purposes  of  this  study,  the  focus  will  be  on  the  planning  process  of  the  DRB 
commander. 

Because  the  DRB  commander  must  adapt  his  force  package  to  the 
mission,  enemy,  terrain  and  weather,  troops,  and  time  available  (METT-T),  he 
must  have  a  total  understanding  of  all  the  assets  at  his  disposal  in  order  to 
effectively  tailor  his  forces.  The  commander  discharges  his  responsibility 
through  an  established  chain  of  command.  The  chain  of  command  is  fixed  and 
each  commander  will  be  encouraged  to  function  properly  through  the 
decentralization  of  authority  commensurate  with  the  responsibility  and 
resources  of  the  subordinate  commander. 


3.5.1  Airborne  Operations  Planning 

In  order  to  ensure  a  smooth  and  effective  airborne  operation,  four 
basic  plans  are  necessary.  These  plans  are  essential  regardless  of  the  type  of 
mission,  size  of  the  force  or  duration  of  the  operation.  The  four  plans  are: 

1.  The  ground  tactical  plan, 

2.  The  landing  plan, 

3.  The  air  movement  plan,  and 

4.  The  marshalling  plan. 
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Inverse,  or  backward  planning  is  essential  in  an  airborne  operation. 
The  ground  tactical  plan  is  always  developed  first  since  this  specifies  what  will 
be  done  at  the  objective  area  and  how  this  will  be  accomplished.  Until  the 
scheme  of  maneuver  is  completed,  there  is  nothing  on  which  to  base  the 
remaining  plans. 

Concurrent  planning  is  an  essential  and  unique  aspect  of  airborne 
operations.  For  example, to  develop  the  division  landing  plan  the  division  G3 
requires  four  items  of  information:  the  commander's  priorities,  subordinate  unit 
ground  tactical  plans,  subordinate  unit  landing  plans,  and  airlift  techniques. 
Since  all  echelons  are  working  under  the  same  time  constraints  this  poses  a 
difficult  challenge.  Concurrent  planning  has  been  developed  to  such  an  extent 
in  the  82nd,  that  division,  brigade,  and  battalion  landing  pians  arc  developed 
and  completed  simultaneously.  The  requirement  for  rapid  exchange  of  data 
between  planning  elements  at  all  echelons  is  obvious.  This  communication  is 
accomplished  using  FM  secure  voice,  secure  telephone,  messenger,  and  land 
lines. 


The  sections  that  follow  illustrate  the  complexity  of  planning  airborne 
operations  and  highlight  some  of  the  factors  that  must  be  considered  by  the 
DRB  commander  and  his  staff. 

3. 5. 1.1  The  Ground  Tactical  Plan.  Based  on  METT-T,  the  airborne  force 
commander  (either  the  DRF  or  DRB  commander  as  appropriate)  will  develop 
the  ground  tactical  plan.  The  mission  may  be  restrictive  or  non-restrictive.  A 
restrictive  mission  requires  an  airborne  force  to  seize  and  secure  a  fixed 
installation  such  as  an  airfield,  an  embassy  complex  or  a  bridge.  The  force 
must  deny  the  enemy  access  to  the  objective  —  a  mission  which  is  primarily 
defensive  in  nature.  A  non-restrictive  mission  is  more  dynamic  and  permits  the 
commander  greater  flexibility  in  its  accomplishment.  This  type  of  mission  is 
associated  with  blocking  the  movement  of  enemy  forces  through  an  area  or 
clearing  an  area.  A  non-restrictive  mission  can  thus  be  offensive  or  defensive  in 
nature.  There  are  five  major  considerations  in  developing  the  ground  tactical 
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plan: 


1.  Assault  objectives, 

2.  Security, 

3.  Task  organization, 

4.  Boundaries,  and 

5.  Reserve. 

Regardless  of  the  ultimate  type  of  mission  assigned,  offensive  and 
defensive  operations  will  initially  be  required.  First,  an  assault  is  made  to 
secure  the  airborne  force  assault  objectives.  These  objectives  provide  the 
initial  security  of  the  airborne  force  and  assist  in  accomplishing  the  mission. 
These  assault  objectives,  once  secured,  must  be  defended  until  the  airborne 
force  is  organized  in  the  objective  area  and  can  continue  the  mission.  The 
defense  of  the  objective  area  can  continue  throughout  the  duration  of  the 
mission. 


Upon  receipt  of  the  warning  order  at  the  N  +  2  briefing,  the 
commander  and  his  staff  will  analyze  the  mission  to  determine  the  stated  and 
implied  tasks  and  whether  the  mission  is  restrictive  or  non-restrictive. 

The  enemy  force  is  then  analyzed  in  terms  of  its  strength, 
composition,  location,  and  possible  reactions  to  the  insertion  of  the  airborne 
force.  The  location  of  the  enemy  force  relative  to  the  objective  area  is 
considered  as  the  most  immediate  and  significant  threat.  The  airborne  force  is 
at  its  most  vulnerable  during  the  first  few  hours  of  the  operation. 

The  terrain  is  analyzed  closely  for  available  drop  zones,  landing 
zones,  and  extraction  zones  in  addition  to  the  usual  significant  terrain  factors 
such  as  obstacles,  fields  of  fire,  cover  and  concealment,  avenues  of  approach 
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and  key  terrain. 


The  commander  must  then  not  only  consider  the  forces  organic  or 
attached  to  his  task  force  but  also  those  from  other  services  since  airborne 
operations  are  by  their  nature,  always  a  joint  operation.  For  example,  Air  Force 
considerations  that  must  be  considered  are  tactical  airlift,  air  reconnaissance, 
and  close  air  support.  In  some  cases,  close  coordination  with  the  Navy  may 
also  be  required. 

The  commander  must  finally  consider  the  length  of  time  of  the 
operation  before  linkup  with  friendly  forces  or  withdrawal  is  accomplished. 
While  these  considerations  are  common  to  the  planning  of  all  military 
operations,  one  must  remember  that  airborne  operations,  unlike  others,  are 
conducted  behind  enemy  lines. 

In  considering  how  to  employ  the  airborne  forces  in  the  objective 
area,  the  commander  must  view  the  mission  from  two  perspectives  —  the 
airhead  and  the  area  of  operations.  The  airhead  is  a  designated  area  that 
when  secured,  permits  the  airlanding  of  follow-on  forces.  The  area  of 
operations  is  a  specific,  much  larger  area,  designated  by  higher  headquarters 
within  which  the  airborne  force  will  operate.  At  one  time,  the  two  concepts  were 
viewed  as  mutually  exclusive,  but  current  doctrine  allows  for  the  combination  of 
the  two. 


Any  feature  that  must  be  secured  to  accomplish  the  unit  mission  or  to 
ensure  the  overall  security  of  the  unit  during  the  initial  phase  of  the  operation 
will  be  designated  as  an  assault  objective  and  considered  a  high  priority  task. 

Security  forces  protect  the  main  body  from  attack,  develop 
intelligence,  and  gain  time  by  disrupting  enemy  attacks.  Security  forces 
employed  by  the  airborne  force  can  include  the  division  recon  platoon,  light 
armor,  or,  when  available,  attack  helicopters  form  the  82nd  Combat  Aviation 
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Brigade. 


Considerations  for  tactically  tailoring  forces  and  designated  unit 
boundaries  include: 

•  The  location,  number,  and  relative  importance  of  assigned 
assault  objectives, 

•  The  enemy  threat  and  its  estimated  reaction  time  to  the 
airborne  operation,  and 

•  Maximizing  the  use  of  terrain  for  mission  accomplishment. 

The  reserve  element  of  the  force  usually  enters  the  AO  as  part  of  the 
assault  echelon  but  is  not  assigned  as  assault  objective. 

3. 5.1. 2  Echelonment  and  the  Landing  Plan.  The  concept  of  echelonment  is 
nothing  more  than  a  management  tool  to  consider  the  appropriate  order  of 
arrival  of  each  element  in  the  objective  area.  The  force  will  be  organized  into 
three  echelons  for  the  airborne  assault.  These  echelons  are  the  assault 
echelon,  the  follow-up  echelon,  and  the  rear  echelon.  Figure  3-3  illustrates  the 
the  Landing  Plan. 

The  assault  echelon  is  the  first  element  to  enter  the  objective  area 
and  contains  those  units  required  in  the  initial  stages  of  the  operation  to  secure 
the  area.  METT-T  will  determine  the  composition  of  the  assault  echelon, 
however,  it  will  be  heavily  weighted  with  combat  troops  in  a  forced  entry  type 
operation. 

The  follow-up  echelon  contains  those  elements  required  to  sustain 
operations.  The  follow-up  echelon  often  contains  the  parent  headquarters  of 
those  units  fragmented  for  the  assault  as  well  as  additional  combat  support  and 
combat  service  support  units. 
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REAR  ECHELON 


OBJECTIVE  NORMANDY 


The  time  interval  between  delivery  of  the  assault  echelon  and  the 
follow-up  echelon  will  depend  primarily  on  the  availability  of  aircraft,  the 
capacity  of  the  departure  airfield,  the  number  of  aircraft  sorties  flown,  and  the 
size  and  number  of  drop  zones  in  the  objective  area.  The  reason  for  the 
distinction  between  the  echelons  is  to  simplify  planning  procedures  by 
establishing  logical  priorities  for  phasing  various  types  of  units  into  the  area. 


The  rear  echelon  remains  at  the  departure  airfield  or  mashalling  area 
during  the  offensive  and  defensive  operations.  It  contains  those  units  that  are 
not  required  in  the  AO  or  can  better  perform  their  functions  in  the  rear. 

It  is  important  to  realize  that  echelonment  applies  to  almost  every  unit 
in  the  division  in  that  even  infantry  battalions  will  have  elements  in  each 
echelon:  combat  elements  in  the  assault,  maintenance  elements  in  the  follow¬ 
up,  and  administrative  and  mess  elements  in  the  rear. 

Once  the  ground  tactical  plan  specifies  which  units  are  to  seize  which 
objectives  and  the  concept  of  echelonment  of  forces  is  developed,  the 
commander  can  begin  to  formalize  the  landing  plan. 

The  landing  plan  specifies  the  sequence  of  delivery,  the  method  of 
delivery,  and  the  place  of  arrival  of  troops  and  equipment  in  the  objective  area. 
The  time  of  delivery  is  not  yet  considered  since  the  sequence  of  arrival  must  first 
be  determined. 

The  landing  plan  is  not  a  formal  plan.  It  is  an  informal  plan  to  ensure 
that  the  air  movement  plan  supports  the  scheme  of  maneuver.  As  an  example, 
the  commander  must  be  able  to  tell  the  airlift  planners,  "I  want  to  drop  x  number 
of  parachutists  on  DZ  Normandy  as  priority  number  1." 

In  small  scale  operations,  where  only  one  drop  zone  is  used,  it  is 
possible  to  determine  the  air  movement  plan  directly  from  the  ground  tactical 
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plan.  However,  even  in  this  instance,  it  will  be  necessary  to  mentally  prepare  a 
landing  plan. 

The  remaining  information  that  planners  must  have  concerns  the 
means  by  which  the  Air  Force  will  deliver  the  airborne  force  to  the  objective 
area.  There  are  a  number  of  different  aircraft  used  by  the  Air  Force  for  strategic 
airlift.  Each  of  these  aircraft  have  unique  capabilities  and  limitations  in  terms  of 
the  number  of  parachutists  and  equipment  they  can  carry.  There  are  also 
various  techniques  that  can  be  used  for  the  delivery  of  heavy  equipment.These 
techniques  will  vary  according  to  METT-T  and  USAF  resources  available.  It  is 
essential  that  the  Army  planners  consider  how  the  Air  Force  intends  to 
accomplish  their  mission  in  order  to  ensure  that  the  arrival  of  troops  and 
equipment  are  synchronized  with  the  ground  tactical  plan.  Examples  of  these 
considerations  are: 

•  Formation  to  be  flown, 

•  Sequence  of  personnel  drop,  heavy  drop,  and  LAPES,  and 

•  Time  interval  between  serials  (serials  are  groups  of  like  aircraft 
with  the  same  method  of  delivery  going  to  the  same  drop 
zone). 

3. 5.1. 3  The  Air  Movement  Plan.  The  air  movement  plan  is  prepared  jointly  by 
the  Army  and  the  Air  Force.  It  covers  the  phase  of  the  operation  form  the  time 
the  units  load  the  aircraft  until  they  arrive  at  the  objective  area.  As  stated  earlier, 
this  plan  directly  relates  to  the  preceding  plans  but  is  primarily  an  Air  Force 
responsibility.  The  air  movement  plan  is  depicted  in  Figure  3-4. 

3.5.1. 4  The  Marshalling  Plan.  The  final  plan  to  be  developed  is  the 
marshalling  plan.  The  marshalling  plan  is  the  process  by  which  units  of  the 
airborne  force  make  final  preparations  for  combat,  move  to  departure  airfields, 
and  load  for  takeoff.  It  begins  when  the  division  is  first  alerted  and  it  continues 
until  all  units  and  equioment  have  been  loaded  onto  the  aircraft.  It  is  essential 
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Figure  3-4.  The  Air  Movement  Plan 


that  many  of  the  functions  required  by  the  marshalling  plan  be  carried  out  by 
units  other  than  the  deploying  unit.  In  the  82nd,  the  DRF  9  is  the  only  battalion 
in  the  division  with  the  same  state  of  readiness  as  the  DRF  1  for  precisely  this 
reason.  Figure  3-5  illustrates  the  marshalling  plan. 

The  supporting  DRF  9,  division  and  corps  support  units  provide 
transportation,  medical,  communications,  food  service,  engineers,  maintenance, 
supply  and  airdrop  equipment.  The  size  of  the  support,  of  course,  varies  with 
the  size  of  the  deploying  force.  Parent  headquarters  of  attachments  deploying 
with  the  task  force  also  have  an  important  role  in  ensuring  that  the  attachments 
have  sufficient  resources  to  support  the  deploying  commander. 

An  important  part  of  the  marshalling  plan  includes  movement  of  the 
force  from  the  unit  areas  to  a  Personnel  Holding  Area  (PHA)  and  to  the 
departure  airfield  itself.  The  planning  functions  described  earlier  are  performed 
continuously  despite  this  movement. 

Actions  taken  by  the  Departure  Airfield  Control  Group  (DACG)  and  the 
Airlift  Control  Element  (ALCE)  at  the  airfield  are  the  culmination  of  the 
marshalling  plan.  These  elements  ensure  that  the  movement  from  the  PHA  to 
the  airfield  and  the  loading  of  the  aircraft  occur  in  accordance  with  the  air 
movement  plan 

3.5. 1.5  Summary.  It  should  be  apparent  from  the  above  descriptions  that  the 
DRB  commander  has  mutliple  factors  to  consider  when  providing  guidance  to 
his  staff  for  their  planning  estimates  and  recommendations  for  the  tactical  plan. 
Also  the  DRB  commander  has  the  ultimate  responsibility  to  approve  all  plans. 
As  a  result,  the  combat  engineer  must  be  in  a  position  to  clearly  state  the 
combat  engineering  operations  plan  such  that  the  DRB  commander  will 
understand  its  implications  for  the  tactical  mission  plan. 
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Figure  3-5.  The  Marshalling  Plan 


3.6  S2ND  AIRBORNE  DIVISION  ENGINEER  SUPPORT 

Every  US  Army  division  has  an  organic  engineer  battalion  to  provide 
continuous  and  responsive  engineer  support.  In  the  82nd  Airborne  Division, 
this  support  is  provided  by  the  307th  Combat  Engineer  battalion.  The  mission 
of  the  307th  is  to  increase  combat  effectiveness  by  providing  mobility, 
countermobility,  survivability,  and  general  engineering  support  to  the  division. 
Figure  3-6  shows  the  composition  of  the  307th  Combat  Engineer  Battalion  of 
the  82nd  Airborne  Division. 

Mobility  missions  include  breaching  enemy  minefields  and  obstacles, 
route  improvement,  and  water  crossing  operations.  Countermobility  operations 
include  the  enhancement  of  fire  through  obstacle  and  minefield  employment. 
Survivability  missions  enhance  the  total  survivability  of  the  force  through 
fighting  and  protective  position  construction.  General  engineering  tasks  are  not 
normally  performed  by  the  combat  engineer  battalion  at  the  division  level  but 
XVIII  Airborne  Corps  can  provide  a  special  force  package  known  as  the  Light 
Airfield  Repair  Package  to  meet  the  division's  unique  requirements. 

Table  3-2  shows  the  equipment  associated  with  the  307th  Engineer 
Battalion.  All  of  the  equipment  can  be  air-dropped.  If  heavier  equipment  is 
required  from  the  Corps  Engineer  Brigade  (20th  Engineer  Brigade,  XVIII 
Airborne  Corps),  it  must  be  air  landed  after  the  objective  area  is  secured. 


Airborne  operations  rely  on  the  precise  synchronization  of  literally 
hundreds  of  key  events.  The  sequence  of  these  events  are  all  driven  by  the 
ground  tactical  plan  which  specifies  the  tactical  objectives  and  the  times  at 
which  they  must  be  achieved.  Once  approved,  the  ground  tactical  plan  serves 
as  the  baseline  for  all  subsequent  decisions.  The  combat  engineer  plays  a  vital 
role  in  advising  the  DRB  commander  on  how  engineer  operations  will 
contribute  to  mission  success.  The  following  section  describes  how  the  CE 
currently  accomplishes  this  demanding  task. 
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TABLE  3-2  Illustration  of  Engineering  Assets 


•  HHC  NUMBER 

D-5  Bulldozer  6 

5  Ton  Truck,  Dump  6 

15  Ton  Trailer  6 

2  1/2  cu  yd  Front  End  Loader  4 

2  1/2  Ton  Truck,  Dump  12 

1  1/2  Ton  Trailer  8 

Grader  4 

250  CFM  Air  Compressor  w/  Pneumatic  Tools  2 

420  Gallon  Per  Hour  Water  Purification  Unit  8 

•  Enor  Co  HQ 

Machine  Gun,  .50  Cal  w/Ring  Mount  and  AA  Mount  1 

Machine  Gun,  7.62mm  2 

Radio  Set,  AN/PRC-77  1 

Radio  Set,  AN/VRC-47  1 

Radio  Set,  AN/VRC-64  1 

Tractor,  Whld  Ind  (JD  410  Backhoe)  1 

Truck,  Cargo,  1  1/4  Ton  2 

Truck,  Cargo,  2  1/2  Ton  1 

Truck,  Dump,  2  1/2  Ton  1 

Truck,  Utility,  1/4  Ton  2 

Trailer,  Cargo,  1/4  Ton  1 

•Eoqr.Ett.tdfl 

Boat,  Recon  3-man  1 

Demo  Set  1 

Machine  Gun,  7.62mm  1 

Radio  Set,  AN/GRC-i  60  1 

Tool  Kit,  Carp,  Engr  Pit  1 

Tool  Kit,  Pioneer,  Engr  Pit  1 

Tool  Outfit,  Portable  Electric  1 

Tracker,  Guided  Missile  (DRAGON)  2 

Trailer,  Bolster,  4  Ton  1 

Truck,  Cargo,  1  1/4  Ton  6X6  i 

Truck,  Dump,  2  1/2  Ton  1 

Truck,  Utility,  1/4  Ton  1 

Tool  Set,  Air  Assault  Engr  Sqd  1 

Trailer,  Cargo,  1/4  Ton  1 

•  Engr  Sad 

Demo  Set  1 

Grenade  Launcher,  M203,  40mm  2 

Machine  Gun,  7.62mm  1 

Radio  Set,  AN/PRC-77  1 

Tool  Kit,  Carp,  Engr  Sqd  1 
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Figure  3-7  shows  how  the  the  307th  provides  direct  and  general 
support  to  the  division.  Each  of  the  three  engineer  companies  is  task  organized 
to  support  and  is  habitually  associatea  with  one  of  the  maneuver  brigades.  For 
example,  Alpha  company  supports  the  1st  Brigade  (504th  Airborne  Infantry 
Regiment)  ,  Bravo  company  supports  the  2nd  Brigade  (325th  Airborne  Infantry 
Regiment)  and  Charlie  company  supports  the  3rd  Brigade  (505th  Airborne 
Infantry  Regiment) 

Figure  3-8  shows  how  each  of  the  three  platoon  organic  to  the  combat 
engineer  company  is  habitually  associated  with  one  of  the  three  battalions 
subordinate  to  the  brigade. 

The  commander  of  the  combat  engineer  company  associated  with  the 
brigade  serves  as  both  the  commander  of  his  company  and  as  a  special  staff 
officer  to  the  brigade  commander.  In  the  role  of  special  staff  officer,  the  company 
commander  is  referred  to  as  the  Assistant  Brigade  Engineer  (ABE).  These  dual 
responsibilities  place  an  extraordinary  burden  on  the  CE  company  commander. 
This  burden  is  exacerbated  by  the  additional  burdens  of  a  time  constrained 
environment,  limited  experience  and  reliance  on  manual  methods  for  acquiring 
and  processing  large  volumes  of  information. 

It  is  the  aim  of  CETOOLS  to  lessen  these  burdens  by  providing  a 
system  that  will  support  the  decision  making  process  of  the  ABE.  The  ABE  is  a 
critical  member  of  the  DRB  staff  and  as  such,  must  be  capable  of  accurately 
assessing  the  tactical  mission  objectives  and  evaluate  the  role  CE  supporting 
units  will  have.  The  ABE  must  perform  this  mission  by  making  multiple 
decisions  under  severe  time  constraints  The  next  section  will  focus  on  these 
critical  planning  activities  performed  by  the  ABE  in  order  to  identify  areas  where 
the  ABE  may  be  in  need  of  decision-aiding  support. 
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Figure  3-7.  Engineer  Company  Support  to  the  Brigades 


3-1 7b 


Figure  3-8.  Engineer  Support  to  the  DRB 


4.0  COMBAT  ENGINEER  PLANNING  AND  DECISION-MAKING  PROCESS 


Our  approach  to  the  design  of  a  decision-aiding  support  system  for 
combat  engineer  planning  activities  is  cognitively-based.  In  analyzing  a  user's 
environment  such  as  faced  by  the  combat  engineer,  it  is  necessary  to 
understand  the  user's  decision-making  process  at  a  level  that  reflects  the 
intrinsic  information  processing  limits  of  human  cognition  which  negatively 
affect  user-computer  interactions  and  decision-making  itself.  With  respect  to 
user-computer  interactions,  it  is  important  to  understand  how  combat  engineers 
perceive  and  use  information  to  make  decisions.  By  so  doing,  user-computer 
interactions  can  be  tailored  and  designed  to  maximize  the  utilization  of  the 
information  obtained  from  such  interactions.  With  respect  to  decision-making,  it 
is  important  to  understand  how  combat  engineers  attempt  to  derive  optimal 
plans  for  engineering  operations  based  on  informational  requirements  and 
tactical  mission  objectives.  By  so  doing,  software  support  can  be  designed  and 
developed  to  assist  the  combat  engineer  in  formulating  optimal  plans.  Critical 
to  this  approach  is  the  identification  of  user  information  processing  limits  to 
effective  decision-making  and  user-computer  interactions.  Based  on  this 
analysis  appropriate  user-computer  interface  technologies  (i.e. ,  computer 
graphics)  and  software  techniques  (i.e.,  Artificial  Intelligence)  can  be  identified 
that  can  extend  the  limits  and  increase  the  quality  of  decision-making  on  the 
part  of  combat  engineers. 

The  following  subsections  will  described  the  decision-making  steps 
that  a  combat  engineer  performs  when  formulating  engineering  plans  to  support 
tactical  commander's  mission  objectives.  The  decision-making  steps  performed 
by  the  Assistant  Brigade  Engineer  in  the  82nd  Airborne  Division  will  illustrate 
this  decision-making  process  for  combat  engineers.  By  so  doing,  combat 
engineer's  decision-making  needs  will  be  identified  that  will  serve  as 
requirements  for  software  support  to  be  incorporated  into  the  proposed  design 
of  the  CETOOLS  system. 


4-1 


4.1  THE  ASSISTANUBRISADEJENGINEEB 

This  subsection  will  describe  the  decision-making  environment  of  an 
Assistant  Brigade  Engineer  in  the  82nd  Airborne  Division.  It  is  essential  to  fully 
understand  the  unique  aspects  of  combat  engineer  operations  in  support  of  an 
airborne  force  before  attempting  to  design  the  automated  aid  that  will  enhance 
the  ABE'S  ability  to  make  timely  and  accurate  decisions. 


The  ABE  is  responsible  for: 


Determining  the  requirements  for  engineer  support  to  include 
recommending  to  the  DRB  commander  the  allocation  of 
resources  and  the  command  and  support  relationships  to  be 
used. 

Advising  the  brigade  commander  on  and  planning  the  use  of 
engineers  in  the  functional  activities  of  mobility, 
countermobility,  survivability,  topography,  general  engineering, 
and  airfield  repair. 

Preparing  the  engineer  portions  of  plans  and  orders  to  include 
the  engineer  annex,  supporting  munitions  annex,  obstacle 
plan,  and  denial  plan. 

Exercising  command  and  staff  responsibility  for  engineer 
operations. 


The  ABE  must  be  integrated  into  the  brigades  decision  flow  early. 
Although  the  ABE  is  not  able  to  attend  the  N  +  2  briefing  to  receive  the  division 
order,  he  will  receive  this  information  from  the  307th  Battalion  commander  and 
Assistant  Division  Engineer  (ADE).  To  effectively  accomplish  his  mission,  the 
ABE  must: 


Receive  the  brigade  warning  order  early,  understand  the 
mission,  and  the  82nd  commander's  intent, 

Participate  in  all  staff  planning  sessions  and  develop  an 
engineer  concept  to  support  the  ground  tactical  plan, 
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Identify  engineer  requirements, 


•  Give  decision  briefings  to  tne  commander  and  the  S3, 

•  Contribute  to  the  brigade  operations  orders. 

•  Monitor  and  coordinate  engineer  operations. 

The  greatest  challenge  faced  by  the  ABE  is  in  his  role  as  a  special 
staff  officer  supporting  the  brigade  commander.  The  brigade  commander, 
normally  a  very  senior  officer  will  rely  on  the  ABE,  a  relatively  junior  officer  for 
fast,  expert  advice  on  engineer  support.  Answers  to  the  brigade  commanders 
questions  and  support  to  his  tactical  plan  must  be  provided  quickly  since  the  N- 
Hour  sequence  allows  little  time  for  lengthy  deliberations.  It  is  extremely 
important  that  the  ABE  has  a  clear  understanding  of  the  interactions  that  must 
occur  between  the  commander  and  his  staff.  Without  such  an  understanding, 
the  ABE  will  be  forced  to  operate  in  an  information  vacuum  and  be  unable  to 
either  support  the  commander  or  direct  his  subordinate  engineer  platoons. 

Every  commander  must  perform  the  following  critical  functions: 

•  Know  the  situation, 

•  Make  decisions, 

•  Assign  missions, 

•  Allocate  resources, 

•  Direct  forces,  and 

•  Sustain  forces. 
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The  commander  has  a  staff  to  assist  him  and  the  staff  fulfills  the 
following  functions: 

•  Gather  information, 

•  Make  estimates, 

•  Anticipate  changes  and  events, 

•  Keep  the  commander  and  the  subordinate  units  informed, 

•  Make  recommendations,  and 

•  Prepare  and  issue  orders  for  the  commander. 

The  commander  is  responsible  for  deciding  how  the  elements  of  his 
command  will  be  employed  to  accomplish  his  missions.  The  commander 
controls  the  operations  of  his  forces  by  the  issuance  of  timely  orders.  It  is  a 
major  function  of  the  staff  to  assist  the  commander  in  arriving  at  and  executing 
his  decisions.  Routine  decisions  may  be  made  by  the  staff  within  the  authority 
delegated  to  them  by  the  commander.  However,  operational  decisions  are  of 
such  fundamental  importance  that  the  commander  must  personally  influence 
the  preparation  of  orders  implementing  these  decisions. 

To  follow  is  a  description  of  the  planning  process  that  the  DRB 
commander  and  his  staff  perform  when  developing  the  mission  tactical  plan. 
The  ABE  is  a  member  of  this  decision-making  team. 


4.2  SEQUENCE  OF  COMMANDER  AND  STAFF  ACTIONS 

The  sequence  of  actions  in  making  and  executing  decisions  involves 
a  series  of  separate  actions  or  steps  known  as  the  sequence  of  commander  and 
staff  actions.  The  basic  sequence  describes  a  logical  and  systematic  procedure 
to  solve  major  problems  and  arrive  at  a  properly  considered  decision.  It  should 
be  noted  that  the  sequence  is  flexible  and  that  steps  may  overlap,  be 
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accomplished  concurrently,  or  even  omitted  in  some  cases.  The  sequence  of 
commander  staff  actions  consist  of  the  steps  described  below. 


4.2.1  Step  1  —  Mission 

Though  estimating  and  planning  are  continuous  in  nature,  they  are 
put  more  into  focus  upon  receipt  of  a  mission.  Normally,  higher  headquarters 
assigns  the  mission,  but  the  commander  may  develop  or  deduce  the  mission.  It 
is  the  mission  or  task  to  be  accomplished  that  activated  the  sequence  of 
commander  and  staff  planning  sequence.  The  commander  may  initiate  his 
mission  analysis  at  this  point.  Mission  analysis  is  discussed  in  step  3  below. 


4.2.2  Step  2  —  Information  Available 

The  staff  provides  the  commander  the  information  available  based  on 
their  knowledge  of  the  latest  facts  and  current  situation.  Subordinated 
commanders  receive  information  concerning  the  mission  (warning  order)  and 
the  situation  as  early  as  practicable  in  the  planning  phase  and  at  least  by  the 
time  staff  estimates  are  being  prepared. 


4-2.3  Step  3  —  Mission  Analysis  and  Planning  Guidance 

Based  on  the  information  available,  the  commander  completes  his 
mission  analysis  and  issues  his  planning  guidance  as  follows: 


1.  The  purpose  of  mission  analysis  is  to  ensure  that  the 
commander  fully  understands  his  mission  and  to  allow  him  to 
develop  those  tasks  that  are  essential  to  the  accomplishment  of 
this  mission.  The  command er,  normally  assisted  by  his  staff, 
performs  his  mission  analysis  by  identifying  the  specified  and 
implied  tasks  in  the  mission.  Specified  tasks  are  those  tasks 
delineated  in  the  mission  received  from  higher  headquarters  or 
the  missions  developed  or  deduced  by  the  commander, 
implied  tasks  are  those  additional  tasks  that  the  commander 
identifies  as  essential  to  ensure  accomplishment  of  the 
mission.  When  identifying  implied  tasks,  the  commander 
should  exercise  caution  not  to  include  tasks  that  are  routine  or 
inherent  in  his  mission.  It  should  be  noted  that  at  brigade  and 
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battalion  levels,  the  commander  will  seldom  develop  implied 
tasks  because  the  division  (or  brigade)  mission  to  its 
subordinate  units  normally  is  quite  definitive. 

2.  Planning  guidance  results  from  the  mission  analysis.  To  guide 
the  staff  along  common  lines  of  investigation  in  the  search  for 
the  best  possible  way  to  accomplish  the  mission,  the  staff  uses 
the  commander’s  planning  guidance  in  preparing  or  revising 
their  estimates.  Planning  guidance  provides  the  necessary 
staff  direction  for  concurrent  planning  by  providing  a  framework 
for  making  studies  and  estimates.  The  amount  of  planning 
guidance  varies  with  each  mission,  the  volume  and  validity  of 
information  available,  the  situation,  and  the  experience  of  the 
commander  and  staff.  Planning  guidance  is  not  limited  to  one 
specific  step  in  the  sequence  of  actions.  However,  initial 
guidance  should  precede  the  preparation  of  estimates. 
Planning  guidance  must  include,  as  a  minimum,  the 
restatement  of  the  mission  as  determined  in  mission  analysis. 
This  stated  mission  is  used  as  paragraph  2,  in  all  of  the  staff 
estimates.  Additionally,  planning  guidance  may  include 
tactical  determinations,  courses  of  action  the  commander 
desires  his  staff  to  consider,  key  terrain  within  the  overall 
objective  area  of  defensive  sector,  use  of  nuclear  and  chemical 
fires,  security,  tactical  cover  and  deception  objective, 
restrictions  on  operations,  allocation  of  means.  Priority 
Intelligence  Requirements  (PIR)  or  other  intelligence 
requirements,  and  pertinent  assumptions.  Unless  higher 
headquarters  has  directed  a  specific  course  of  action,  the 
commander  does  not  select  or  specify  a  course  of  action  at  this 
time  because  to  do  so  would  prevent  objective  and  unbiased 
staff  estimates. 


4.2.4.  Step  4  —  Staff  Estimates  (Including  Recommendation^ 

The  staff  members,  having  received  the  commander’s  planning 
guidance,  are  prepared  to  focus  their  individual  efforts  on  the  problem  to  be 
solved.  It  involves  a  consideration  of  all  circumstances  affecting  the  situation 
and  a  systematic  analysis  and  evaluation  of  possible  ways  to  accomplish  the 
task  or  mission.  Staff  officers  furnish  information,  conclusions,  and 
recommendations  through  preparation  of  an  estimate.  They  summarize  the 
significant  aspects  of  the  situation,  evaluate,  and  determine  how  the  means 
available  can  best  be  employed  to  accomplish  the  mission.  The  development 
of  individual  estimates  requires  staff  officers  to  consult  with  each  other  to  insure 
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coordination  of  all  factors  affecting  the  situation.  When  the  mission  requires  a 
basic  decision  as  to  the  tactical  employment  of  the  unit,  the  operation  estimate, 
made  by  the  S3,  is  the  key  staff  estimate  and  incorporates  the  conclusions  of 
the  other  staff  estimates*.  This  then  becomes  the  coordinated  staff 
recommendation.  As  the  staff  concurrently  prepares  their  estimates,  the 
information  provided  by  and  furnished  to  each  is  as  follows: 


1.  The  S2  furnishes  the  SI,  S3,  and  S4  with  the  results  of  his 
analysis  of  the  weather,  terrain,  and  enemy. 

2.  The  SI  and  S4  provide  the  S3  with  information  pertaining  to 
the  personnel  situation  and  logistic  support,  respectively. 

3.  The  S3  determines  the  possible  courses  of  action  he  plans  to 
consider  in  his  operation  estimate  and  advises  the  other  unit 
staff  officers. 

4.  The  S2  refines  his  own  estimate  in  the  light  of  the  courses  of 
action  given  him  by  the  S3  and  plans  for  the  production  of 
additional  intelligence,  if  appropriate. 

5.  Based  on  the  information  received  from  other  staff  members 
and  an  evaluation  in  their  own  areas  of  responsibility,  the  SI 
and  S4  complete  their  estimates  to  determine  what  major 
problems  exist  in  providing  the  required  support  and  which  of 
the  proposed  courses  of  action  can  best  be  supported  from  a 
personnel  (SI)  and  logistical  (S4)  viewpoint. 

6.  Meanwhile,  the  S3  completes  his  operation  estimate.  The 
result  will  be  the  determination  of  that  course  of  action  which 
offers  the  greatest  probability  of  success  from  a  tactical 
viewpoint,  i.e.,  operation  recommendation.  After  coordination 
with  other  staff  members,  to  include  consideration  of  any 
advantages  or  limitations  developed  as  a  result  of  their 
estimates,  the  operation  recommendation  becomes  the 
coordinated  staff  recommendation. 
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7.  The  S3  presents  the  coordinated  staff  recommendation  to  the 
commander  as  a  statement  of  the  general  scheme  of  maneuver 
to  be  adopted.  The  S3  should  comment  upon  any  significant 
problems  and  elaborate  on  the  recommendation  to  the  extent 
necessary  to  insure  that  the  commander  is  fully  informed.  As 
desired,  the  commander  will  question  the  staff  officers  for 
additional  information  needed  to  arrive  at  his  decision. 


4.2.5.  Sten  5  —  Commander's  Estimate  (including  Decision  and  Concept) 
The  commander's  estimate  consists  of  the  following  processes: 


1.  While  the  staff  members  are  each  completing  their  estimates, 
the  commander  is  concurrently  making  his  own  estimate.  He 
may  consult  with  his  staff  members  during  this  time.  His 
estimate  prepares  him  to  receive  and  evaluate  the  staff 
recommendation  and  to  make  a  decision. 

2.  Upon  receipt  of  the  recommendation  of  the  staff,  the 
commander  completes  his  estimate  and  states  his  decision.  In 
a  tactical  situation,  the  decision  is  a  statement  of  the  general 
scheme  of  maneuver  (placement  and  movement  of  major 
maneuver  elements)  to  be  adopted  and,  if  applicable,  any 
nuclear  fires  (nuclear  rounds  to  be  fired  and  their  targets,  or 
nuclear  rounds  to  be  held  in  reserve  or  on  call  status).  It  is 
based  on  the  course  of  action  offering  the  greatest  probability 
of  success  in  accomplishing  the  unit's  mission. 

3.  To  assist  the  staff  members  in  preparing  the  detailed  plans  to 
execute  the  decision,  the  commander  usually  elaborates  upon 
the  decision  by  stating  his  concept  to  his  staff.  These 
instructions  outline  to  the  staff  the  intent  of  the  commander  with 
regard  to  the  operation.  Although  detailed  plans  are  made  by 
the  staff,  the  commander  should  outline  the  direction  he 
desires  the  plan  to  take.  No  form  is  prescribed  for  this  concept, 
although  it  may,  at  the  commander's  discretion,  include 
additional  guidance,  and  elaboration  on  the  general  scheme  of 
maneuver,  organization  for  combat,  general  plan  of  fire 
support,  combat  service  support,  and  other  details  for 
preparation  of  the  orders. 

4.  The  commander's  decision  and  concept  are  the  basis  for 
preparation  of  paragraph  3A,  Concept  of  the  Operation,  of  the 
operation  order  by  the  S3. 
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4.2.6.  Step  6  —  Preparation  of  Plans  or  Orders 

Although  the  staff  plans  continuously,  it  is  not  until  they  receive  the 
commander's  decision  with  respect  to  the  tactical  employment  of  the  unit,  that 
their  plans  can  be  finalized.  Throughout  their  estimates  the  staff  develops 
areas,  not  essential  to  the  commander’s  basic  decision,  requiring  further  study 
and  planning.  Having  received  the  commander's  decision  and  concept,  the 
staff  must  finalize  all  of  the  operational  details  by  continuing  with  their  planning 
and  preparing  the  orders  necessary  to  implement  the  commander's  decision. 
The  S3  has  primary  staff  responsibility  for  the  preparation  of  the  operation  plans 
or  orders  (oral  or  written). 


4.2.7.  Step  7  —  Approval  of  Plans  or  Orders 

The  operation  plan  or  order  is  presented  to  the  commander  for 
approval.  This  step  may  be  omitted  if  the  urgency  of  the  situation  so  warrants 
and  if  a  higher  commander  has  delegated  such  authority. 


4.2.8.  Step  8  —  Issuance  of  Plans  or  Orders 

After  approval,  the  S3  supervises  final  preparation  of  the  plan  or 
order,  authenticates  copies  and  insures  proper  distribution  if  issued  in  written 
form.  At  battalion  level,  oral  orders  are  often  used.  Time  permitting,  written 
orders  may  be  published  to  confirm  or  change  the  oral  order,  or  to  serve  official 
record  purposes. 


4.2.9.  Step  9  —  Supervision 

After  the  order  is  issued,  the  commander  and  staff  supervises  its 
execution.  The  primary  purpose  of  the  staff  in  this  respect  is  to  assist 
subordinate  units  wherever  possible  to  carry  out  the  intent  of  the  commander’s 
order. 


4-9 


4.3  APPLICATION  OF  THE  SEQUENCE  OF  COMMANDER  AND  STAFF 

ACTIONS 

The  extent  to  which  each  of  the  above  steps  (exclusive  of  the 
decision)  will  be  performed  personally  by  a  commander  depends  on  a  number 
of  factors.  Some  of  these  factors  are:  time  available,  the  size  of  the  command, 
the  situation,  and  the  experience  and  training  of  the  commander  and  the 
members  of  his  staff.  However,  it  must  be  recognized  that  the  manner  in  which 
these  steps  are  performed  and  their  relationship  to  each  other  depends  on 
many  factors.  The  basic  sequence,  described  in  Section  4.2,  describes  a 
logical  and  systematic  procedure  to  solve  major  problems. 

The  very  nature  of  staff  activities  requires  that  many  of  the  steps  be 
acted  upon  concurrently  by  individual  sections.  Delineation  of  staff 
responsibilities  often  overlaps  the  areas  of  interest  between  staff  officers  and 
requires  not  only  close  supervision,  but  mutual  assistance  as  well. 

Particularly  at  brigade  level,  the  sequence  is  applied  on  an  informal 
basis.  Time  available,  experience  of  the  commander  and  his  staff,  and  the 
relative  urgency  of  the  situation  may  necessitate  variations  in  application  of  the 
sequence.  Nonetheless,  the  basic  steps  of  this  sequence  of  commander  and 
staff  actions  are  employed  to  ensure  the  best  possible  solution. 


4.4  ROLE  OF  THE  ABE  DURING  THE  PLANNING  PROCESS 

During  the  brigade  planning  process,  the  ABE  will  study  maps, 
imagery,  and  terrain  intelligence  to  formulate  the  engineer  plan.  The  engineer 
plan  will  be  a  detailed  task  analysis  to  quantify  the  requirements  for  the  mission, 
the  recommended  task  organization,  and  required  augmentation  from  either  the 
307th  Battalion  or  the  20th  Engineer  Brigade  belonging  to  the  Corps. 

The  development  of  the  engineer  plan  must  be  flexible  to  ensure  that 
it  adapts  to  changing  requirements  throughout  the  N  -  Hour  sequence. 
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The  ABE  must  coordinate  with  several  other  engineer  decision  nodes 
to  include  the  assistant  division  engineer  (ADE),  the  307th  commander  and  S3, 
and  the  DRF  engineer  platoon  leaders. 

Communications  between  the  ABE  and  the  307th  commander  is 
essential  in  order  to  maximize  the  use  of  engineer  assets.  The  commander  will 
allocate  assets  on  a  mission  priority  basis.  Communication  with  the  ADE 
ensures  that  engineer  information  and  intelligence  at  the  division  level  is 
passed  to  the  ABE  in  a  timely  fashion.  Subordinate  platoon  leaders  must  be 
kept  informed  of  the  overall  brigade  plan  and  be  supported  by  the  ABE.  During 
the  N-Hour  sequence  this  communication  is  performed  largely  by  face  to  face 
meetings  and  messenger.  Currently,  there  is  no  secure  means  of  transferring 
data  in  an  automated  fashion. 


Once  deployed  in  the  Area  of  Operation,  the  ABE  will  rely  on 
messengers,  secure  FM  voice  radios,  radio  teletype  and  multi-channel  systems. 


Within  the  DRB  planning  cell,  the  ABE  must  interface  with  the: 


Intelligence  Officer  (S2)  —  Based  on  the  S2’s  intelligence 
preparation  of  the  battlefield,  the  ABE  can  estimate  the 
combined  effects  of  enemy,  weather,  and  terrain  on  mobility, 
countermobility,  and  survivability  planning.  Using  terrain 
analysis  and  estimates  of  the  threat  engineers  capabilities,  the 
S2  and  the  ABE  determine  the  enemy’s  most  likely  avenue  of 
approach.  Together  the  two  staff  officers  will  identify  choke 
points,  obstacles,  and  trafficability.  If  the  objective  of  the 
airborne  operation  includes  seizing  an  airfield,  it  will  be 
especially  important  to  know  the  status  of  the  airfield. 

Operations  Officer  (S3)  —  With  the  S3,  the  ABE  receives  the 
brigade  commander's  intent  and  guidance,  develops  estimates 
and  courses  of  action,  and  develops  input  to  the  brigade 
operations  order  to  include  assembly  on  the  DZ  and  linkup  with 
heavy  drop  equipment,  assault  objectives,  logistics  release 
points,  and  follow-on  missions. 
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Logistics  Officer  (S4)  —  The  ABE  provides  early  estimations  of 
the  class  IV  (construction  material)  and  class  V  (munitions) 
supplies  needed  to  fulfill  the  engineers  requirements. 
Especially  important  is  coordinating  transportation  of  these 
supplies  from  the  DZ  to  the  engineer  squads  dispersed 
throughout  the  airhead. 

Fire  Support  Officer  (FSO)  —  the  ABE  coordinates  with  the 
FSO  to  ensure  that  all  obstacles  are  covered  by  fire.  Obstacles 
must  appear  on  the  fire  Support  overlay  as  target  reference 
points.  Coordination  is  also  required  to  ensure  pre-planned 
artillery  delivered  scatterable  mines  enhance  both  the 
maneuver  and  obstacle  plans. 


There  are  two  extremely  significant  constraints  upon  the  ABE's 
planning  process.  The  first  is  time.  With  only  eighteen  hours  to  plan  for  a 
mission,  the  ABE  engineer  is  often  forced  to  rely  on  intuition  and  experience  to 
make  critical  decisions.  The  second  is  resources  since  airborne  forces  are 
severely  constrained  by  the  limitations  of  strategic  airlift. 


4.5  COMBALENGINEER  DECISION  SITUATION 

In  order  to  understand  the  internal  cognitive  processing  that  the  ABE 
performs  in  developing  his  plans,  we  applied  a  decision  analysis  methodology 
that  characterizes  the  decision  functions  that  the  ABE  performs  within  the 
context  of  his  overall  high  level  goal  or  objective  (e.g.,  support  the  DRB 
commander's  tactical  mission  plan).  By  examining  the  high  level  interactions 
between  decision  functions,  a  unit  of  analysis  —  the  decision  situation  —  can 
be  determined.  The  decision  situation  is  the  most  amenable  unit  of  analysis  to 
a  cognitively-based  decision  analysis. 

This  analysis  will  serve  as  the  basis  for  determining  the  functional 
design  and  the  nature  of  the  user-computer  interactions  for  the  proposed 
CETOOLS  system.  Past  efforts  in  applying  this  unit  of  analysis  have 
successfully  identified  decision  making  needs  for  various  kinds  of  military 
decision-makers.(Zachary,  et  al.,  1981;  Zaklad,  et  al.,1986) 
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The  decision  situation  for  the  ABE  is  characterized  as  follows: 


The  ABE  strives  to  support  the  ground  tactical  plan  by 
identifying  the  mobility,  countermobility  and  survivability 
operations  that  must  be  performed  in  support  of  the  tactical 
mission.  Included  in  the  ABE’S  assessment  are  the  resources, 
assets,  and  time  needed  to  perform  engineering  operations 
within  each  of  the  combat  engineering  tasks  and  balancing 
those  estimates  versus  available  resources.  This  activity 
represents  the  major  decision  situation  faced  by  the  ABE. 


The  following  subsections  describe  the  decomposition  of  the  major 
cognitive  information-processing  activities  that  the  combat  engineer  (ABE) 
performs  with  respect  to  the  above  decision  situation.  This  decomposition  will 
serve  as  the  basis  for  identifying  the  user  requirements  that  must  be  addressed 
by  the  proposed  CETOOLS  for  the  combat  engineer.  See  Section  5  for  a 
general  description  of  decision-aiding  support  systems  and  the  rationale 
supporting  this  type  cf  cognitively-based  decision  analysis. 


4.5.1  Decision  Situation  for  the  Combat  Engineer 

This  decision  situation  is  described  below,  and  summarized  in  Table 

4-1. 

4.5.2  Objective 

Combat  Engineers  support  the  tactical  commander's  mission  through 
a  mix  of  mobility,  countermobility,  survivability  and  general  engineering  tasks. 
The  unique  considerations  of  airborne  operations,  however,  present  the 
airborne  engineer  with  numerous  decisions  in  the  face  of  severely  constrained 
resources.  The  deployment  of  airborne  forces  will  normally  occur  under 
circumstances  of  great  urgency  with  little  time  to  develop  detailed  plans.  In 
many  cases  the  tactical  situation  at  the  objective  area  will  radically  change  even 
before  the  deployment  is  complete.  The  introduction  of  the  airborne  force  into 
the  objective  area  will  be  incremental  and  possibly  subject  to  hostile  action. 
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Airborne  engineer  operations  are  heavily  driven  by  the  mission,  the 
duration,  the  airflow  and  the  tactical  environment.  Based  on  these 
considerations,  the  engineer  decision  maker  must  continually  reevaluate  and 
prioritize  the  relative  level  of  effort  directed  toward  the  goals  of  mobility, 
countermobility,  survivability  and  general  engineering.  In  the  airborne  decision 
making  environment,  changes  in  the  tactical  situation  may  impact  on  decisions 
made  hours  earlier  and  thousands  of  miles  away. 

Thus,  the  airborne  combat  engineer  requires  a  decision  aid  that  will 
allow  him  to  rapidly  assimilate  new  information,  accurately  assess  its  impact  on 
his  mission  and  provide  him  with  the  ability  to  make  the  necessary  changes  to 
the  time  phased  deployment  of  the  task  force’s  engineer  support. 


4.5.3  Task  Dynamics 

Because  the  decision  situation  is  basically  repeated  each  time 
additional  reports  or  messages  arrive,  the  dynamics  of  the  decision  situation 
can  be  characterized  as  a  closed  loop  iterative.process.  Thus,  the  combat 
engineer  must  repeatedly  perform  the  following  steps: 


Receive  the  mission  from  the  commander  and  understand  its 
implications  for  engineer  operations. 

Analyze  the  area  of  operations  so  that  the  combined  effects  of 
weather  and  terrain  on  operations  will  be  fully  considered.  In 
the  case  of  82nd  Airborne  operations  this  information  is  often 
fragmentary  and  must  be  continually  evaluated  as  it  is  received 
throughout  the  planning  cycle. 

Identify  the  commander's  specific  and  implied  tasks.  From  this 
list  of  tasks,  the  combat  engineer  will  determine  which  of  these 
tasks  are  absolutely  essential  to  the  accomplishment  of  the 
mission.  Having  identified  the  essential  tasks,  the  engineer  is 
able  to  restate  the  mission  as  a  series  of  engineering  tasks  to 
be  performed. 
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Evaluate  all  assets  available  to  include  personnel,  equipment 
and  materiel.  Additions  or  shortfalls  to  what  is  currently 
available  must  be  identified  . 

Constraints  and  limitations  placed  on  engineer  operations 
must  be  identified  and  incorporated  into  the  engineer'  s 
decision.  These  include  limitations  due  to  aircraft,  airflow  and 
logistical  requirements. 

Continually  analyze  the  time  available  for  planning  and 
executing  operations.  Time  is  a  particularly  critical 
consideration  is  airborne  operations  since  there  is  not  only  a 
limited  amount  of  time  in  which  to  plan  the  operation  but  all 
critical  tasks  must  be  performed  exactly  on  time  so  that  the 
ground  tactical  plan  is  supported  by  the  airflow. 

Present  his  decision  in  the  form  of  a  plan  to  the  commander 
and  supervise  the  execution  of  the  plan  or  make  revisions  as 
required. 


4.5.4  Choice  Criteria 

At  any  point  in  time,  the  Combat  engineer  is  faced  with  the 
requirement  to  decide  which  types  of  information  are  needed  to  enhance  his 
understanding  of  the  overall  tactical  situation  and  his  ability  to  support  the 
mission  through  engineer  support.  That  is,  the  Combat  engineer  must  choose 
the  essential  pieces  of  information  relating  to  METT-T  that  he  feels  will  have  the 
greatest  value  in  allowing  him  to  quickly  evaluate  the  impact  of  the  information 
without  time-consuming  perusal  of  excessive  and  irrelevant  data  (information 
overload).  Similarly,  the  Combat  engineer  must  decide  what  vital  information  is 
lacking  and  forcing  him  to  make  assumptions  or  decisions  without  the  required 
data.  Applying  this  criterion  requires  a  high  degree  of  knowledge  about  the 
implications  of  each  combat  engineering  task.  For  example,  the  combat 
engineer  may  be  inundated  with  terrain  and  climate  studies  that  fail  to  provide 
him  with  the  weather  in  the  last  24  hours  and  its  effect  on  trafficability  in  the 
primary  enemy  avenue  of  approach. 
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4.5.5 


Underlying  Process 

The  process  that  underlies  the  Combat  Engineer's  decision  situation 
are  the  implications  of  the  ground  tactical  plan  with  respect  to  future  combat 
operations.  The  combat  engineer  must  make  his  choices  for  information  and 
subsequent  decisions  relate  to  the  emerging  picture  of  the  objective  area,  the 
commander's  evolving  plan,  and  the  possible  outcomes  that  may  result  from 
combat.  Because  of  the  complexity  inherent  in  such  a  dynamic  situation,  it  is 
almost  impossible  to  anticipate  the  course  of  events  and  actions  that  may  occur 
beyond  those  standard  actions  anticipated  in  division  standard  operating 
procedures 


4.5.6  Information  Environment 

The  types  of  information  that  the  Combat  engineer  requires  are 
characterized  as  follows: 


Inputs:  There  are  many  dynamic  inputs  to  the  Combat 
Engineer's  decision  making.  These  include  primarily 
information  on  the  elements  of  METT-T.  All  of  these  variables 
will  be  changing  throughout  the  duration  of  the  deployment 
and  subsequent  combat  operations  while  the  Combat  engineer 
is  conducting  his  assessment  of  how  to  best  support  the 
operation  with  combat  engineering  support. 

Parameters:  There  are  some  elements  of  information 
available  to  the  engineer  decision  maker  that  will  not  change 
during  the  course  of  the  decision  making  process.  Among 
these  are  the  basic  missions  of  combat  engineer  and  the 
means  to  accomplish  them,  the  basic  structure  of  the  command 
and  control  relationships  of  the  DRB,  the  physical  constraints 
of  the  transport  aircraft,  and  the  critical  events  that  must  occur 
in  order  to  deploy  the  task  force  in  eighteen  hours. 
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Outputs:  In  the  course  of  the  engineer  assessment,  the 
engineer  will  determine  his  critical  tasks  and  the  priority  in 
which  they  will  be  accomplished.  This  determination  will  often 
be  informally  coordinated  with  the  commander  and  other  staff 
officers  before  a  final,  approved,  decision  is  made  as  to  how 
engineer  assets  will  be  employed.  Based  on  the  commander's 
decision  for  engineer  employment,  the  plans  and  orders  are 
prepared.  These  operational  plans  or  orders  (OPLAN  or 
OPORD)  will  be  written  or  presented  orally  by  the  combat 
engineer  as  an  annex  to  the  supported  task  force  OPORD  and 
as  a  separate  OPORD  to  subordinate  engineer  units.. 


4.5.7  Intermediate  Reasoning  and  Analysis  Steps 

There  are  several  steps  that  the  Combat  engineer  will  follow  in  order 
to  arrive  at  his  decision,  based  on  his  intuition,  and  professional  judgement. 
The  accuracy  of  his  decision  based  on  these  factors  will  be  directly  related  to 
his  experience  and  training.  The  engineer  first  must  recognize  the  desired  end 
toward  which  his  efforts  are  directed  in  order  to  focus  his  reasoning  and 
analysis.  Second,  he  must  establish  a  baseline  of  the  initial  conditions  based 
on  an  analysis  of  the  engineer  tasks  involved  and  the  knowledge  needed  to 
accomplish  these  tasks.  For  example,  he  must  know  the  composition  and 
capabilities  of  the  engineering  assets  at  his  disposal.  Next,  the  engineer  must 
create  plausible  visualizations  of  situations  and  formulate  a  hypothesis  on  the 
possible  outcome  of  decisions.  The  objective  here  is  to  predict  those  events 
that  are  most  likely  to  occur  and  assess  the  impact  of  those  events  on  the  task 
objectives.  During  the  development  of  the  ground  tactical  plan,  for  instance,  the 
engineer  mentally  considers  the  effect  of  each  obstacle  emplaced  on  the 
movement  of  an  enemy  armored  force.  His  first  inclination  may  be  to  believe 
that  the  enemy  will  establish  a  hasty  defense  and  await  the  arrival  of  breaching 
equipment.  The  engineer  must  then  identify  gaps  in  his  knowledge  about  the 
situation  being  visualized  so  that  he  can  gather  the  information  and  reduce  his 
uncertainty  to  an  acceptable  level.  After  identifying  these  gaps,  the  obvious 
next  step  for  the  engineer  is  to  gather  and  interpret  the  information  he  needs  to 
test  his  hypothesis.  For  example,  when  the  engineer  is  considering  the  effect  of 
an  obstacle  on  the  enemy's  armored  force,  he  will  require  information  on  what 
actions  are  prescribed  by  enemy  doctrine  upon  confronting  an  obstacle.  This 
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new  information,  once  gathered  and  interpreted  will  allow  the  engineer  to  test 
his  original  hypothesis  based  on  his  perceptions  of  the  reliability  and  validity  of 
the  information.  If  the  engineer  receives  and  accepts  information  that  indicates 
enemy  doctrine  dictates  that  all  obstacles  will  be  bypassed  immediately,  this 
contradicts  his  original  hypothesis.  On  the  other  hand,  if  his  baseline 
knowledge  of  the  terrain  indicates  that  bypassing  the  obstacle  is  impossible, 
his  originally  theory  is  validated  by  the  fact  that  the  evidence  supports  it  better 
than  any  rival  hypothesis.  If  a  decision  cannot  be  reached  based  on  the 
available  evidence,  the  engineer  may  choose  to  defer  his  decision  until  such  a 
time  as  new  information  is  received.  In  the  airborne  planning  environment, 
however,  the  engineer  will  not  be  able  to  afford  the  time  required  to  create  a 
complete  picture  of  the  battlefield.  In  these  instances,  decisions  will  revolve 
around  division  standard  operating  procedures. 


4.5.8  Decision  Representation 

The  combat  engineer's  reasoning  steps  used  to  determine  how 
engineer  assets  will  be  employed  in  support  of  the  ground  tactical  plan  explicitly 
involve  the  use  of  maps  and  graphic  overlays  to  aid  in  the  decision  making 
process. 


4.5.9  Required  Quantitative  Judgements 

There  are  numerous  quantitative  judgements  made  by  the  combat 
engineer  when  arriving  at  a  decision.  These  judgements  are  based  on  the 
existence  of  large  volumes  of  empirical  data  that  exist  for  engineer  operations. 
This  data  is  in  the  form  of  tables  and  formulae  that  describe  the  necessary 
expenditure  of  personnel,  resources  and  time  in  the  accomplishment  of  many 
engineer  functions.  While  these  functions  will  be  situationally  dependent  ,  the 
existing  data  provides  a  useful  starting  point  in  arriving  at  decisions. 

A  summary  of  the  decision  situation  just  described  is  provided  in 

Table  4-1 . 
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TABLE  4-1 


COMBAT  ENGINEER  DECISION  MAKING 


DECISION  SITUATION:  Develop  a  plan  that  supports  the  tactical 

commander's  mission  through  a  combination 
of  mobility,  countermobility,  survivability  and 
general  engineering  operations. 

TASK  DYNAMICS:  Closed  loop  iterative 

SITUATIONAL  OBJECTIVE:  Provide  continuous  evaluation  of 

requirements  for  engineer  support  to  the 
ground  tactical  plan. 

CHOICE  CRITERIA: 


1 .  Information  related  to  METT-T 

2.  Trade-off  analysis  between  mobility,  countermobility,  survivability  and 
general  tasks. 


UNDERLYING  PROCESS:  Formulation  of  the  ground  tactical  plan  during 

the  N-Hour  sequence  and  its  implications  with 
respect  to  actual  battle. 


INFORMATION  ENVIRONMENT: 
Inputs _ 

Mission 

Enemy 

Terrain 

Troops  available 
Time 


Outputs: _ Parameters 

Plans  CE  Missions 

Orders  CE  Techniques 

Force  Structure 
Aircraft 

N-Hour  Sequence 


INTERMEDIATE  REASONING/ANALYSIS  STEPS: 

1.  Recognize  goals. 

2.  Establish  baseline 

3.  Create  hypothesis 

4.  Identify  gaps  in  knowledge. 

5.  Gather  and  interpret  information. 

6.  Test  hypothesis. 

7.  Make  decision. 


REPRESENTATION:  Standard  military  maps  and  graphic  overlays 

showing  topographic  data,  the  location  of 
enemy  and  friendly  forces  ,  and  planned 
engineer  operations  will  be  required  to 
facilitate  decision  making. 


REQUIRED  JUDGEMENTS:  THE  CE  WILL  BE  REQUIRED  TO  MAKE  BOTH 

QUALITATIVE  AND  QUANTITATIVE 
JUDGEMENTS. 
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4.6  SUMMARY 

The  ABE'S  requirements  tor  software  support  to  aid  in  decision 
making  can  be  summarized  as  follows: 


Support  in  evaluating  and  prioritizing  combat  engineer 
objectives  with  respect  to  the  mission,  resources,  and  time. 
The  ABE  also  requires  the  capability  to  examine  multiple 
mission  scenarios. 

Support  in  visually  depicting  key  terrain  features,  OPFOR 
assets  and  planned  engineer  operations. 

Support  in  managing  and  maintaining  status  of  engineer 
assets  and  resources. 

Support  in  identifying  the  aircraft  and  logistical  requirements  to 
support  the  engineer  plan. 
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5.0  DECISION-AIDING  SUPPORT  SYSTEMS 


Decision-aiding  support  systems  are  unique  among  computer-based 
information  systems  in  that  their  common  label  arises  not  from  their  shared 
technology  or  common  application  but  rather  from  their  intended  effect  -- 
improving  human  decision-making  performance.  The  discipline  of  decision- 
aiding  represents  a  recognition  by  scientists  from  several  fields  that  decision 
makers  are  in  need  of  computer  assistance  that  alleviates  or  minimizes  the 
complexity  involved  in  evaluating  situations.  This  discipline  encompasses 
several  disciplines  such  as  cognitive  science,  psychology,  and  computer 
science  as  well  as  technologies  such  as  data  base  management,  expert 
system,  and  artificial  intelligence.  Because  of  the  diversity  of  disciplines  and 
technologies  that  are  involved  in  the  design  and  development  of  decision- 
aiding  support  systems,  it  may  not  always  be  apparent  how  such  systems  work 
or  what  they  are  needed  for. 

This  section  will  attempt  to  clarify  this  multi-discipline  area.  This 
section  will  discuss  several  definitions  that  help  to  clarify  the  distinction  between 
decision-aiding  support  systems  and  other  types  of  computer  systems,  the 
reasons  for  developing  such  systems,  and  finally  the  software  techniques 
and/or  technologies  that  have  been  applied  in  the  development  of  decision- 
aiding  support  systems. 


5.1  DEFINITIONS 

Several  authors  have  espoused  that  decision-aiding  support  systems 
differ  from  other  computer  systems  such  as  management  information  systems 
and  automatic  data  processing  systems  based  on  several  considerations. 
These  considerations  are  the  following: 

•  The  type  of  problem  that  decision-aiding  support  systems  are 
designed  to  address, 
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•  The  type  of  support  that  decision-aiding  support  systems 
provide,  and 

•  The  significance  that  such  software  support  provides  to  the 
decision-maker. 

Keen  and  Scott-Morton  (1978)  define  decision-aiding  support 
systems  from  the  viewpoint  of  the  role  that  such  systems  are  to  play.  They  see 
such  systems  as  assisting  decision  makers  in  their  decision  processes 
especially  in  semistructured  tasks,  support  but  not  replace  human  judgement, 
and  improve  the  effectiveness  of  decision-making. 


Alter  (1975)  defines  decision-aiding  support  systems  by  making  the 
distinction  between  traditional  automated  data  processing  (ADP)  applications’ 
and  decision-aiding  support  systems’  goals.  Decision-aiding  support  systems 
are  designed  to  help  managers  (decision  makers)  make  decisions  whereas 
ADP  systems  are  designed  to  automate  clerical  tasks  and  foster  efficient  record 
keeping.  Alter  further  distinguishes  decision-aiding  support  systems  based  on 
the  requirement  for  greater  user  involvement  with  such  systems  than  with  ADP 
systems.  Also,  decision-aiding  support  systems  are  characterized  as  providing 
data  that  decision  makers  request  in  a  manner  that  depicts  the  significance  of 
such  data  (via  process  models)  in  order  to  allow  decision  makers  to  make  a 
judgement. 

Finally,  Sprague  and  Carlson  (1982)  distinguish  decision-aiding 
support  systems  from  traditional  ADP  systems  by  the  nature  of  the  relationship 
between  the  user  and  the  decision-aiding  support  system.  They  see  this 
relationship  as  one  that  requires  a  symbiosis  between  the  decision  maker  and 
the  system  to  be  effective. 


It  is  apparent  from  this  brief  discussion  of  definitions  that  decision- 
aiding  support  systems  are  intended  to  assist  but  not  replace  human 
judgement.  Decision-aiding  support  systems  represent  a  unique  class  of 
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computer  systems  that  are  designed  to  alleviate  or  reduce  the  complexity 
involved  in  analyzing  situations  as  represented  by  information.  A  critical 
question  however  remains  unanswered  from  this  discussion.  What  are  the 
circumstances  that  dictate  the  need  for  computerized  assistance  such  that 
decision  makers  are  better  able  to  make  sound  judgements?  The  following 
subsection  will  address  this  important  question. 


5.2  SITUATIONS  REQUIRING  DECISION-AIDING  SUPPORT 

To  understand  the  situations  that  dictate  the  need  for  decision-aiding 
support,  one  must  first  be  cognizant  of  the  underlying  assumptions  that  form  the 
framework  for  such  descriptions.  Specifically,  the  human  information¬ 
processing  architecture  has  deficiencies  and  limitations  that  interact  with 
situational  demands  such  that  decision  makers  are  at  a  disadvantage  in 
assessing  situations.  As  a  result,  decision  makers  will  be  prone  to  make 
judgements  that  can  be  characterized  as  less  than  optimal.  It  is  because  of 
these  human  information-processing  limitations  that  decision-aiding  support 
systems  are  needed.  Specifically,  such  systems  are  intended  to  overcome  or 
lessen  human  information-processing  inadequacies  so  that  decision  makers 
are  better  able  to  make  sound  judgements. 

The  approach  needed  to  identify  the  situations  and  circumstances 
that  require  decision-aiding  support  must  be  one  that  is  cognitive  in  nature.  To 
do  so  requires  an  understanding  of  the  limitations  that  humans  have  in 
assessing  situations  as  a  result  of  information-processing  inadequacies.  Based 
on  previous  efforts,  Analytics  has  developed  a  framework  that  characterizes  the 
cognitive  processes  involve  in  acquiring,  organizing,  and  retrieving  information 
which  may  hinder  a  decision-maker's  ability  to  assess  a  situation  and  decide 
upon  an  optimal  course  of  action  (Zachary,  et  al.,  1981,  Zaklad,  et  al.,  1986). 
These  cognitive  processes  and  the  situations  and  circumstances  that  may 
interact  with  these  cognitive  processes  are  summarized  below.  They  represent 
the  possible  circumstances  in  which  decision-aiding  support  may  be  warranted. 
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1) 


Ability  to  predict  processes  —  If  there  is  an  underlying  process, 
does  the  person  have  difficulty  predicting  it  in  the  time 
available?  Or,  could  they  make  better  decisions  if  they  had 
good  process  predictions?  Humans  have  difficulty  projecting 
real-world  processes  forward  into  the  future,  especially  when 
the  processes  involve  uncertainty  (e.g.,  combat). 

2)  Ability  to  combine  competing  attributes  or  objectives  —  If 
multiple  criteria  must  be  combined  or  multiple  alternatives 
compared,  is  the  decision  maker  able  to  do  so  reliably  and 
without  bias?  In  many  decision  situations,  several  attributes  or 
criteria  can  describe  an  expected  outcome  of  a  decision  (e.g., 
its  cost  in  expendable  hardware,  its  cost  in  time,  its  gain  in 
enemy  losses,  etc.)  or  must  be  evaluated  to  make  trade-offs 
among  competing  objectives  (.e.g,  mobility  vs.  countermobility). 
When  many  possible  outcomes  must  be  compared  to 
determine  the  best  one,  the  combination  of  these  attributes  can 
be  difficult,  especially  if  they  are  all  numerical.  This  arises  from 
the  limitations  in  short  term  memory  and  in  ability  to  process 
numeric  information  (see  Simon,  1981,  and  Dawes,  1979). 

3)  Ability  to  manage  information  needed  in  the  decision, process 
—  If  a  large  amount  of  knowledge  and/or  data  must  be 
manipulated,  is  the  person  able  to  do  so  in  the  time  available? 
Is  the  person  ignoring  available  information  or  knowledge  in 
favor  of  faster  or  less  mentally  taxing  rules  of  thumb?  Decision 
makers  often  fail  to  make  use  of  all  the  information  available  to 
them  simply  because  they  are  unable  to  manage  it  effectively 
"in  their  head."  This  is  particularly  true  in  tactical  decision 
situations  where  there  is  a  large  volume  of  data  coming  in  from 
sensor  and  message  network  sources  and  a  large  quantity  of 
knowledge  that  needs  to  be  applied  selectively  to  the  available 
information.  Because  all  information  being  used  in  the 
decision  process  must  pass  through  the  very  limited  short  term 
memory  and  because  people  have  unreliable  recall  processes 
from  long  term  memory,  a  human  decision  maker  can  easily  be 
overwhelmed  by  a  large  amount  of  information.  As  a  result,  he 
may  fail  to  process  key  inputs  or  fail  to  recall  and  apply  crucial 
pieces  of  knowledge.  Decision  makers  may  make  excessive 
use  of  "rules  of  thumb"  or  other  "quick-and-dirty"  formulae  that 
provide  simple  generalizations  of  much  more  complex  pieces 
of  knowledge/information. 
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4)  Ability  to  analyze  or  reason  about  the  situation  —  If  the  person 
has  specialized  ways  of  thinking  about  a  problem,  is  he  able  to 
apply  these  within  the  time  and  mental  resources  available? 
Does  he  know  ways  of  attacking  the  decision  that  could  yield 
better  results  but  can't  be  applied  within  the  limited 
time/resources  available?  Difficulties  in  analyzing  decision 
problems  arise  from  a  broad  combination  of  basic  human 
information  processing  limitations,  including  the  size  of  short 
term  memory,  the  difficulties  in  performing  numerical 
calculations,  and  the  inability  to  project  processes  forward  in 
time.  Because  each  decision  situation  involves  a  different 
unaided  decision  process,  the  kinds  of  analysis  and  reasoning 
problems  that  people  have  in  decision  making  vary  a  great 
deal. 

5)  Ability  to  visualize  —  If  the  person  has  a  mental  model  of  the 
problem,  particularly  a  visual  model,  does  he  need  or  want  to 
make  manipulations  of  it  that  he  can't  on  a  completely  mental 
imagery  basis?  People  tend  to  use  visual  representation  in 
their  unaided  decision  processes,  but  they  frequently  have 
difficulties  in  manipulating  these  representations,  particularly  in 
a  quantitative  manner.  For  example,  a  decision  maker  may 
visualize  a  tactical  problem  in  a  map-like  fashion,  but  will  be 
unable  to  mentally  calculate  where  a  target's  trajectory  will 
cross  his  own  path.  This  is  another  instance  of  the  general 
inability  to  perform  quantitative  calculations  mentally.  At  the 
same  time,  however,  people  are  much  better  able  to  make 
such  quantitative  projections  with  their  visual  representations  if 
they  can  deal  with  a  concrete  (i.e.,  explicitly  drawn) 
representation  instead  of  a  purely  mental  one. 

6)  Ability  to  manipulate  Quantitative  information  — If  quantitative 
judgments  are  needed,  is  the  person  able  to  make  them 
without  bias  and  within  the  needed  range  of  accuracy?  There 
are  many  situations  where  the  human  decision  maker  is 
required  to  make  some  inferences  that  can  only  be  described 
as  "judgment  calls."  Highly  skilled  and  experienced  decision 
makers  can  make  such  judgments  with  high  reliability  and 
consistency,  but  when  they  have  a  numeric  aspect  to  them, 
there  is  often  a  systematic  bias  or  "noise"  in  the  judgments 
provided  (see  Kahneman  and  Tversky,  1982). 


The  six  cognitive  processes  and  the  circumstances  just  described 
represent  potential  situations  which  may  require  decision-aiding  support  for 
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decision  makers.  In  Section  4  of  this  report,  we  have  characterized  for  the 
combat  engineer  those  circumstances  that  are  in  need  of  decision-aiding 
support  because  of  human  information-processing  architecture  inadequacies. 

The  identification  of  software  solutions  to  overcome  or  minimize  the 
impact  of  these  situations  is  just  as  important  as  the  identification  of  the 
situations  that  require  decision-aiding  support.  The  following  subsection 
describes  functional  categories  of  decision-aiding  software  techniques  and 
technologies  that  may  be  appropriate  to  overcome  or  lessen  human 
information-processing  inadequacies. 


5.3  TAXONOMY  QF  SOFTWARE  TECHNIQUES  AND  TECHNOLOGIES 

Because  decision-aiding  support  systems  have  entailed  a  plethora  of 
software  techniques  and  technologies,  there  may  seen  at  first  glance  to  be  no 
systematic  way  to  characterize  the  use  of  such  techniques  and  technologies. 
Based  on  previous  efforts,  Analytics  has  devised  a  taxonomy  that  offers 
direction  in  the  use  of  such  techniques  and  technologies  (Zachary,  1980; 
Zaklad,  et  al.,  1986).  This  taxonomy  of  technologies  for  decision-aiding  support 
systems  is  based  on  a  review  of  publications  both  within  and  outside  of  DoD 
and  is  presented  in  Figure  5-1.  The  figure  presents  an  overview  of  the  complete 
taxonomy  down  to  the  second  and  third  levels.  The  identified  technologies 
include  a  variety  of  information  management  aids,  problem  analysis/reasoning 
techniques,  and  judgment  refinement/amplification  methods.  The  six  general 
cognitive  deficiencies  described  in  Section  5.2  and  the  associated  technologies 
found  in  the  taxonomy  that  may  overcome  or  lessen  these  cognitive  deficiencies 
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Decision  Aiding  Technology 


Figure  5-1.  Decision-aiding  technique  taxonomy. 


are  described  below: 


Underlying  process  ==>  process  prediction  problems 

—  can  be  improved  through  the  use  of  process  models  which 
are  algorithmic  or  mathematical  models  that  calculate  or 
predict  the  outcome  of  a  real-world  process,  i.e.,  a  situation 
which  unfolds  over  real  time.  They  are  useful  in  problems 
where  the  decision  maker  has  only  partial  or  no  control  over 
the  outcome  of  the  process.  For  example,  in  air  battle 
management,  the  decision  maker  controls  the  actions  of  his 
own  forces,  but  cannot  control  those  of  the  enemy.  In  such 
situations,  outcome  calculators  may  be  used  to  predict  the 
result  of  the  process  given  a  proposed  course  of  action  and  an 
estimate  or  set  of  alternative  estimates  concerning  the  possible 
actions  of  the  enemy.  Examples  of  process  models  include 
Lanchester  equations  which  predict  attrition  of  forces  in  battle 
(Lanchester,  1916,  Craig,  1975),  battle  engagements  (Gamero, 
et  al.,  1978),  and  air  strike  timing  decision  aids  (Glenn  and 
Zachary,  1978,  Epstein,  1978). 

Choice  criteria  ==>  difficulties  in  combining  attributes 

—  can  be  improved  through  the  use  of  choice  models  which 
describe  or  guide  the  user  in  weighing  of  all  information  that  is 
available  on  all  alternatives  and  selecting  one  for  further 
attention  or  implementation.  Choice  models  may  be  designed 
to  systematically  integrate  attributes  of  decision  alternatives, 
either  mathematically  in  the  form  of  multi-attribute  utility  models 
(see  Weisbrod  et  al.,  1977),  sequentially  in  the  form  of  aspect 
models  (see  Tversky,  1972),  or  constructed  as  collections  of 
production  rules  which  embody  di/erse  problem-related 
knowledge  (see  Duda  and  Shortliffe,  1983). 

Information  requirements  ==>  difficulties  in  retrieving 
information  —  can  be  assisted  through  information  control 
techniques  for  accessing,  organizing,  and  monitoring  data  and 
knowledge.  These  include  database  management  functions 
(see  Martin,  1980,  for  a  review),  numerical  analysis  techniques 
(see  Irving  et  al.,  1977),  and  alerters  (Buneman  and  Morgan, 
1977). 
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Intermediate  analyses  ==>  problems  in  analyzing  or 
reasoning  —  can  be  improved  through  the  use  of  analysis 
and  reasoning  methods  dependent  upon  whether  the  problem 
involves  numeric  or  symbolic  information  and  whether  the 
inferences  is  goal-based  (e.g.,  the  General  Problem  Solver  of 
Newell,  Shaw,  and  Simon,  1965),  data-driven  (e.g,  the  KNOBS 
system  (Engleman  et  al. ,  1979)  for  air  battle  management),  or 
process-based  (e.g.,  Vere,  1983  for  mission-planning). 

Decision  representation  ==>  difficulties  in  visualizing 
or  relating  data  to  a  mental  model  —  can  be  improved 
through  the  use  of  representation  aids  for  the  form  in  which 
information  is  presented  to  the  human  verbally  or  spatially. 
The  principal  aiding  techniques  for  verbal  representations  are 
natural  language  processing  (see  Rich,  1984)  and  automated 
speech  processing  (an  application  of  automated  speech  in  the 
Forward  Area  Alerting  Radar  (FAAR)  workstations  in  the 
SHORAD  system  is  described  by  Smyth,  1985).  The  principal 
visual  representation  techniques  are  computer  graphics  (see 
Rubenstein  and  Hersh,  1984),  windowing,  (see  Buneman  et 
al.,  1977),  and  quickening  (see  Birmingham  and  Taylor,  1954). 

Required  judgments  ==>  quantitative  inaccuracies  in 
heuristic  judgments  —  can  be  improved  through  the  use  of 
judgement  refinement/amplification  techniques  such  as 
decision  structuring  (see  Pearl  et  al.,  1980),  Bayesian 
updating,  human-aided  optimization  (see  Schecterman  and 
Walsh,  1980  and  Hurst  and  Krolak,  1982),  and  adaptive  user¬ 
modeling  and  extrapolation  (see  Weisbrod  et  al.,  1977). 


By  providing  this  set  of  functional  categories  of  decision  support,  a 
taxonomy  of  decision-aiding  technologies  and  techniques,  and  its  relationship 
to  human  information-processing  inadequacies,  one  is  able  match  the 
appropriate  techniques  that  offer  a  solution  to  a  decision  maker's  inability  to 
adequately  assess  a  situation  and  reach  a  sound  judgement.  In  Section  7  of 
this  report,  the  appropriate  software  techniques  and  technologies  with  respect 
to  the  combat  engineer  needs  for  decision-aiding  support  are  described  in  the 
context  of  the  proposed  functional  design  for  the  CETOOLS  system. 
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6.0  USER  COMPUTER  INTERFACE  TECHNOLOGIES 


The  CETOOLS  system  will  provide  powerful  capabilities  to  the  user  to 
assist  them  in  their  role  as  CE  in  developing  engineering  plans.  However, 
these  functions  will  go  to  waste  if  the  user  finds  it  difficult  to  communicate  with 
CETOOLS,  specify  the  characteristics  of  their  problems,  or  decipher  the  results. 
Therefore,  the  nature  of  the  user  computer  interface  (UCI)  is  a  critical 
determinant  to  the  successful  use  of  CETOOLS.  This  section  presents  the 
results  of  research  conducted  into  several  critical  areas  for  the  user  interface, 
namely  the  user-computer  dialog  and  user  profiling. 

This  discussion  of  user  interfaces  assumes  that  CETOOLS  will  be 
developed  on  a  microcomputer  and  that  the  microcomputer  is  equipped  with  1) 
a  high  resolution  color  graphics  monitor  with  windowing  capability,  2)  a  pointing 
device  such  as  a  mouse,  and  3)  direct  graphics  input  device  such  as  a  digitizing 
tablet.  A  mouse  is  a  small  box  (about  the  size  of  a  deck  of  playing  cards)  with 
one  to  three  buttons  on  its  top  face  that  functions  as  a  pointing  device.  The 
mouse  motion  translates  into  corresponding  movements  of  a  pointer  (e.g.,  a 
cursor)  on  a  display.  It  allows  the  user  to  manipulate  information  and  select 
commands  or  locations  on  the  screen  without  having  to  enter  specialized 
interface  commands  via  the  keyboard.  A  digitizing  tablet  is  a  separate  touch- 
sensitive  surface  operated  with  a  pointing  device  such  as  a  stylus  that  can  he 
used  to  trace  over  graphical  material  for  direct  entry  of  coordinate  information. 

Since  it  was  decided  that  CETOOLS  is  to  provide  a  highly  visual 
interface,  particular  attention  was  paid  to  guidelines  available  for  designing 
interactive  graphic  interfaces.  Fairly  detailed  and  comprehensive  guidelines 
have  been  developed  for  various  areas  of  UCI’s,  including  keyboard  design, 
display  legibility,  and  ergonomic  considerations,  that  are  based  on  empirical 
data  which  has  been  organized  in  several  reference  handbooks  (Engle,  1975, 


6-1 


and  Brown,  1983).  Unfortunately,  few  guidelines  are  available  to  assist  the 
designer  in  developing  interactive  interfaces  that  take  full  advantage  of  the 
features  accorded  by  a  highly  graphic  system.  This  section  will  present  "guiding 
principles"  but  it  is  expected  that  the  exact  nature  of  the  user  interface  will 
evolve  iteratively  in  conjunction  with  the  development  of  the  CETOOLS 
prototype  through  early  and  extensive  involvement  of  the  proposed  user 
community  and  their  feedback.  This  interaction  between  the  CETOOLS 
designers  and  the  CE  community  is  critical  to  the  successful  development  of  the 
system  in  order  to  ensure  the  system  effectively  meets  the  needs  of  the  user. 
The  exact  nature  of  the  user  interface  will  also  be  considered  in  conjunction 
with  system  requirements  such  as  time  criteria.  Sophisticated  user  interfaces 
frequently  make  heavy  demands  on  the  system  and  and  trade-offs  may  be 
required  to  ensure  that  the  benefits  of  the  user  interface  are  not  nullified  by  slow 
system  response  time. 


This  section  presents  a  compendium  of  the  following  interface  design 
issues  considered  relevant  for  the  CETOOLS  UCI  and  any  available  design 
principles: 


Interactive  Dialogue  —  identify  the  techniques  used  for 
communications  between  the  user  and  CETOOLS  including 
dialogue  style  and  user  aids. 

Input  Capabilities  —  identify  the  appropriate  input  devices 
(e.g.,  keyboard,  mouse,  graphic  tablet,  etc.)  and  their  use  for 
user  communication  with  the  system  for  the  CE  functions. 

Output  Capabilities  —  determine  how  information  is  to  be 
presented  to  the  user  in  such  a  way  that  maximizes  tne  user's 
perception  and  understanding  of  information  including  screen 
design  and  layout,  use  of  color,  and  use  of  graphics. 


6.1  INTELLIGENT  USER  DIALOGUE 

One  of  the  key  issues  in  designing  a  user  interface  is  the  selection  of 
the  techniques  used  for  communications  between  the  user  and  the  computer. 
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This  not  only  involves  selection  of  a  dialogue  type,  but  the  development  of 
techniques  to  assist  and  guide  the  user's  interactions  with  the  computer  system. 
As  described  in  Section  2,  CETOOLS  users  will  possess  varyir-'  levels  of 
computer  usage  skills  and  CE  expertise.  The  user-computer  interface  (UCI) 
must  supply  a  meaningful  structure  within  which  the  two-way  dialogue  between 
the  user  and  CETOOLS  occurs. 

6.1.1  Dialogue  Types 

The  user  communicates  with  the  system  by  specifying  commands  and 
objects  to  be  manipulated.  There  are  six  primary  dialogue  types  that  are 
relevant  for  a  decision  support  system  such  as  CETOOLS: 

1.  Command-Driven, 

2.  Menu-Driven, 

3.  Question-Answer, 

4.  Form  Fill-in, 

5.  Graphics-Driven,  and 

6.  Natural  Language. 

Each  dialogue  structure  type  has  a  particular  user  appeal  depending  on  a 

user’s  knowledge  of  the  system  and  their  computer  expertise.  Many  systems 
are  now  based  on  a  hybrid  of  these  techniques. 

6.1. 1.1  Command-Driven  Dialogues.  Command-driven  dialogues  typically 
display  a  brief  prompt  to  the  user  (e.g.,  a  question  mark)  and  expect  the  user  to 
type  in  a  command  name,  phrase,  or  associated  mnemonic  (e.g.,  PRINT  or  PR). 
Since  the  system  offers  very  few  prompts  or  choices,  the  user  is  expected  to 
know  which  system  features  are  currently  available  and  their  syntax.  If  the 
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system  does  not  recognize  a  command  that  the  user  enters,  it  typically  responds 
with  an  error  message.  The  biggest  advantage  of  a  command-driven  interface 
is  speed.  Very  few  keystrokes  are  required  to  initiate  any  action,  and  it 
eliminates  stepping  through  multiple  levels  of  menus  to  specify  an  action. 
Command-driven  interfaces  appeal  to  experienced  users  since  the  system 
functions  are  more  readily  accessible.  Command  dialogue's  biggest 
shortcoming  is  its  inherent  "unfriendliness.’'  A  system  or  computer  novice 
viewing  a  display  with  nothing  but  a  prompt  has  no  guide  as  to  what  to  do  next. 
Novice  users  have  many  problems  learning  a  command  dialogue  system  since 
they  are  unfamiliar  with  both  the  functions  that  can  be  accomplished  and  the 
command  names  required  to  invoke  the  functions.  Additionally,  in  order  to 
invoke  a  command,  the  user  has  to  first  remember  the  designated  command.  If 
there  are  too  many  commands  to  be  able  to  remember  them  easily,  users  tend 
to  find  this  facility  too  frustrating  and  time-consuming  to  use. 

6. 1.1. 2  Menu-Driven  Interfaces.  Menu-driven  interfaces  display  every 
possible  choice  that  the  user  can  make  in  a  menu  that  is  typically  arranged  in  a 
hierarchical  manner  (i.e.,  one  choice  or  action  must  be  taken  before  another). 
The  selection  of  one  menu  item  generates  another  menu,  which  brings  up  yet 
another  until  a  final  selection  allows  the  desired  function  to  be  accomplished. 
The  major  advantage  provided  by  menu  dialogues  is  the  ability  to  guide  a  user 
through  the  steps  needed  to  accomplish  a  task.  Menus  reduce  memory 
demands  because  they  only  require  the  user  to  recognize  rather  than  recall  the 
correct  option  (Martin,  1973).  However,  menu-driven  interfaces  are  not  without 
problems.  New  users  might  find  that  learning  larger  systems  is  difficult  because 
information  must  be  integrated  across  a  series  of  displays.  As  each  menu  is 
viewed  in  isolation,  relationships  between  menus  are  difficult  to  grasp  and  the 
user  may  get  lost  in  the  hierarchical  structure.  However,  menu  interfaces  do 
facilitate  use  by  novices.  On  the  other  hand,  experienced  users  are  often 
frustrated  when  they  must  step  through  a  number  of  menus  before  reaching  the 
desired  function  since  not  all  functions  are  available  from  all  menus. 
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A  strategy  that  is  effective  for  workstations  with  display  windowing  and 
mouse  capabilities  is  the  pull-down  menu  that  combines  command  and  menu- 
driven  techniques.  Pull-down  menus  display  a  command  bar  at  the  top  of  a 
window  with  a  submenu  displayed  in  a  new  window  box  beneath  it  showing  all 
available  options.  The  user  can  use  the  mouse  to  move  a  pointer  to  one  of  the 
choices  displayed  in  the  box.  As  the  pointer  moves  among  the  menu  options, 
the  current  selection  is  highlighted  and  the  user  depresses  a  keyboard  or 
mouse  key  to  indicate  the  desired  selection. 

6. 1.1. 3  Question  and  Answer  Dialogues.  Question  and  Answer  (Q&A) 
dialogues  present  the  user  with  a  series  of  questions  to  which  the  user 
responds  one  at  a  time.  The  question  and  answer  process  is  repeated  until  the 
system  has  received  the  necessary  information.  Q&A  dialogues  typically  decide 
the  next  question  based  upon  the  answer(s)  to  the  previous  question(s).  Some 
incorporate  a  degree  of  natural  language  capabilities  in  order  to  avoid  simple 
yes/no  responses.  If  the  system  cannot  understand  a  response  or  require 
additional  information,  clarification  questions  may  be  generated.  Similarly,  if 
the  user  cannot  understand  a  question,  an  explanation  facility  is  typically 
provided.  Q&A  dialogues  are  typically  used  in  advice  providing  expert  systems. 

Q&A  dialogues  are  most  successful  with  novices  who  are  unfamiliar 
with  the  problem  to  be  solved.  However,  experienced  users  quickly  become 
impatient  when  forced  to  step  through  a  lot  of  questions.  One  way  to  alleviate 
this  problem  is  to  provide  multiple  modes  of  use  —  e.g.,  full  sentence  mode  and 
abbreviation  mode.  Additionally,  default  response  can  be  set  for  the  particular 
user  (this  is  described  in  more  detail  in  Section  6.2)  as  part  of  their  "user 
profile."  An  additional  consideration  is  how  to  permit  the  user  to  change  the 
response  to  a  previous  question.  Finally,  the  ability  of  Q&A  dialogues  to  be 
utilized  within  the  time  constraints  imposed  on  the  CE  needs  to  be  considered 
since  Q&A  dialogue  techniques  require  a  certain  amount  of  time  per  question. 
This  fact  generally  precludes  their  usage  for  time  critical  applications. 
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6. 1.1. 4  Form  Fill-In  Interfaces.  Form  fill-in  (or  fill-in-the  blanks)  interfaces 
provided  the  user  with  input  forms  in  which  the  user  enters  necessary 
commands  and  data.  A  display  of  labeled  fields  and  an  area  for  entry  of  input 
are  shown  and  the  user  moves  the  cursor  between  the  input  areas  and  enters 
the  appropriate  information.  This  type  of  design  is  well  suited  when  there  is  a 
correspondence  between  the  input  display  and  paper  forms  familiar  to  the  user. 
This  type  of  interface  requires  the  user  to  be  cognizant  of  the  field  labels, 
permissible  field  values,  and  the  data  entry  techniques  to  be  employed  in 
moving  among  the  displayed  fields.  Form  fill-ins  are  most  appropriate  for 
frequent  users. 

A  variant  of  form  fill-ins  are  input  templates  developed  on  computers 
with  graphics  capabilities.  In  addition  to  boxes  for  entry  of  text  material,  various 
fields  can  be  defined  to  be  check  boxes  for  on/off  parameters,  click  boxes  for 
parameters  containing  ranges  of  numbers,  and  radio  buttons  for  the  user  to 
select  only  one  of  a  set  of  parameters.  Recent  research  in  the  area  of  input 
templates,  such  as  those  used  on  the  Apple  Macintosh  computer,  will  be 
considered  in  the  development  of  the  user  interface  (Smith  et  al.,  1982  and 
Norman  and  Draper,  1986). 

6. 1.1. 5  Graohics-Driven  Interfaces.  Graphics-driven  interfaces  are  a  fairly 
recent  development  and  generally  provide  an  interface  that  is  both  "friendly" 
and  non  restrictive.  Graphic  icons  replace  or  supplement  words  as  command 
designators  in  menu-based  systems.  Instead  of  a  temporal  order  display  such 
as  a  menu,  the  user  is  presented  with  a  spatial  order  of  possible  actions  that  are 
represented  by  "iconic"  or  pictorial  representations  of  actions.  The  user 
positions  a  graphics  pointer,  such  as  a  mouse,  over  the  icon  representing  the 
desired  action.  Icons  take  advantage  of  the  human  ability  to  discern  pictorial 
differences  more  quickly  and  easily  than  textual  differences.  However,  the 
icons  must  be  designed  carefully  in  order  to  maximize  their  usefulness  and  are 
best  suited  when  a  limited  set  of  clearly  distinguishable  options  are  available. 
The  visual  interfaces  made  possible  by  iconic  representation  provide  an  object 
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orientation  rather  than  a  procedure  orientation  and  enhance  the  user's 
knowledge  about  the  system  and  its  capabilities.  However,  there  currently 
exists  a  very  limited  body  of  information  about  the  effectiveness  of  iconic 
representations  and  how  they  should  be  designed  to  maximize  information 
transfer. 

6. 1.1. 6  Natural  Language  Interfaces.  Natural  language  interfaces  provide 
the  ability  of  the  computer  software  to  process  plain  English  user  requests. 
English  is  a  very  complex  language  and  contains  many  structural  and  semantic 
ambiguities.  This  complexity  requires  a  vast  amount  of  knowledge  in  order  to 
understand  even  a  simple  sentence.  Although  unrestricted  natural  language  is 
the  least  limiting  to  the  user,  it  is  not  currently  practical  to  timely  machine-parse 
with  available  computer  systems  and  technology  because  of  it's  extreme 
complexity.  Many  advances  are  being  made  in  the  field  of  natural  language 
processing  but  it  is  doubtful  that  they  could  be  incorporated  into  CETOOLS  in 
the  near  future  without  significantly  affecting  the  machine  resources  available  to 
the  primary  function  of  CETOOLS,  i.e.,  assisting  the  CE  in  decision-making 
functions.  Additionally,  a  body  of  evidence  suggests  that  limiting  the  vocabulary 
and  syntax  available  to  the  user  improves  the  user’s  ability  to  utilize  and 
comprehend  the  system  language  (Bailey,  1985;  Hendler  and  Michaelis,  1983). 
Other  studies  have  shown  that  arbitrarily  approximate  treatments  of  natural 
language  may  cause  more  problems  than  they  solve  (Bornw,  Burton,  and 
deKleer,  1982). 

6.1. 1.7  User  Dialogue  Recommendations.  It  is  recommended  that  the  initial 
dialogue  style  for  the  prototype  CETOOLS  system  be  a  combination  of  menus 
and  input  templates  as  illustrated  in  Section  7.  Menu-bars  can  be  used  to  show 
a  list  of  available  CETOOLS  functions  on  a  line  at  the  top  of  the  screen.  Pull¬ 
down  menus  can  list  submenus  in  a  separate  window  displayed  beneath  the 
menu  bar  and  will  contain  the  list  of  commands  available  for  a  particular 
selection  from  the  menu  bar.  Once  the  user  has  specified  the  CETOOLS 
function,  additional  dialogue  with  the  user  will  occur  using  a  series  of  input 
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templates.  Since  many  of  the  parameters  specified  by  the  combat  engineer 
utilize  standard  symbiology  (e.g.,  obstacles,  unit  designators  and  capabilities, 
etc.)  these  will  be  represented  by  icons  where  appropriate.  As  described 
above,  the  exact  nature  of  the  UCI  will  be  developed  iteratively  in  conjunction 
with  the  user  community. 


6.2  USER  AIDS 

User  aids  provide  the  means  to  assist  the  user  in  making  effective  use 
of  the  system.  They  must  be  implemented  in  a  consistent  manner  both  for  the 
user  indicating  that  additional  assistance  is  needed  and  in  the  form  of  the 
assistance. 

6.2.1  HELP  Kevs 

Supplementary  on-line  guidance  in  the  form  of  brief  command 
summaries  and  tool  descriptions  which  assist  the  user  in  making  decisions  is  an 
essential  feature  of  a  user-friendly  system.  HELP  displays  serve  as  cognitive 
development  tools  to  assist  the  user's  understanding  of  the  system.  A  simple, 
standard  action  that  is  always  available  to  the  user  should  be  developed  to 
obtain  HELP  messages.  For  example,  HELP  might  be  requested  by  an 
appropriately  labeled  function  key,  by  selection  of  an  always  available  menu 
option,  or  by  keying  a  question  mark  into  a  displayed  entry  area.  The  content  of 
the  HELP  response  should  be  related  to  the  contents  of  the  current  display  or 
the  current  sequence  of  activity.  The  explanations  should  be  developed  in 
conjunction  with  the  user  community  in  order  to  tailor  the  response  to  the  user’s 
likely  needs. 


6.2.2  Default  Values 

Default  values  represent  the  systems  best  guess  of  the  responses 
expected  by  users.  They  must  be  developed  carefully  to  represent  clear, 
logical,  and  meaningful  values.  The  use  of  default  values  can  both  speed  data 
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entry  and  reduce  input  errors  for  a  defined  task.  The  default  values  should  be 
clearly  displayed  in  a  consistent  manner.  The  user  should  have  the  capability 
to  easily  define,  change,  or  remove  default  values  for  any  data  entry  field.  In 
addition  to  the  default  values  specified  by  the  system  developers,  the  user 
should  also  be  allowed  to  override  and  specify  defaults  where  appropriate  — 
such  as  the  specification  of  the  units  of  measurement. 


6.2.3  Status  Information 

Status  (or  progress)  information  which  signifies  that  the  system  is 
performing  a  time-consuming  function  and  which  also  provides  an  approximate 
indication  of  when  the  function  will  be  completed  is  also  an  important  user  aid. 
Information  is  provided  to  the  user  to  indicate  that  the  system  is  actually  doing 
something  and  is  not  waiting  for  any  user  actions  in  order  to  continue  execution. 
Since  the  CE  may  be  interrupted  at  any  point  to  perform  a  more  critical  task,  the 
availability  of  status  information  will  allow  the  analyst  to  make  a  determination 
about  whether  to  continue  or  terminate  the  current  function. 


6.3  INPUT  CAPABILITIES 

6.3.1  Input  Devices 

6. 3.1.1  Keyboards.  Alphanumeric  keyboards  used  for  data  entry  should 
conform  to  the  Qwerty  arrangement  and  the  keyboard  should  include  a  keypad 
to  assist  in  entry  of  numeric  data  (Van  Cott  and  Kinkade,  1972). 

6. 3.1. 2  Pointing  Devices.  The  UC1  also  requires  the  use  of  a  device  that  can 
point  quickly  to  items  on  the  display  and  that  are  faster  than  the  directional 
cursor  keys  such  as  a  mouse,  joystick,  trackball,  light  pen,  etc.  Of  these  devices 
that  are  commonly  available,  the  mouse  has  been  identified  as  the  preferred 
one  for  most  video  pointing  needs.  The  mouse  is  a  hand-held  pointing  device 
with  a  sensor  on  the  bottom  to  detect  motion  over  a  flat  surface  and  one  to  three 
buttons  on  the  top  which  can  be  sensed  by  system  software.  The  system 
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provides  the  user  with  continuous  feedback  as  fo  where  it  thinks  the  mouse  is 
pointing  by  displaying  a  cursor  on  the  screen.  The  user  slides  the  mouse 
around  on  a  flat  surface  (causing  the  bearings  or  wheels  on  the  bottom  of  the 
mouse  to  rotate),  and  the  system  moves  the  cursor  on  the  display.  The  user 
indicates  that  the  mouse  has  positioned  the  cursor  at  the  desired  location  by 
pressing  a  button  on  the  top  of  the  mouse. 

The  most  common  use  of  a  mouse  is  to  move  a  cursor  to  a  precise 
screen  location  and  depress  a  mouse  button  in  order  to  initiate  some  action, 
such  as  selecting  a  menu  option,  that  otherwise  would  require  the  depressions 
of  special  function  keys  and/or  directional  cursor  movement  keys.  The  mouse  is 
the  preferred  pointing  device  for  text-editing  applications  because  it  is  the  most 
comfortable  to  use  and  is  also  among  the  fastest  (Card,  et  al,  1978,  Warfield, 
1983). 

6.3. 1.3  Direct  Graphics  Input.  CETOOLS  requires  a  method  to  rapidly  and 
easily  specify  selected  graphics  information  for  map  and  terrain  information. 
The  CE  will  generally  be  given  a  map  of  the  area  of  operation.  In  order  to 
transfer  this  information  into  CETOOLS,  a  digitizing  tablet  would  be  used  to  that 
the  CE  would  move  a  pointer  (e.g.,  a  stylus  or  puck)  over  the  surface  of  the  map 
which  had  been  placed  on  the  tablet.  At  each  point  where  critical  information  is 
to  be  specified,  a  tablet  buttons  would  be  pressed  to  indicate  the  type  of 
information  to  be  entered.  Single  point  data  can  be  entered  as  well  as 
continuous  information  such  as  curves.  The  computer  display  would  provide 
information  about  the  entered  information  and  the  status  of  the  tablet.  In 
addition  to  the  information  on  the  map,  the  CE  could  also  directly  enter 
information  such  as  obstacle  emplacement  by  using  the  pointer  to  trace  over  the 
desired  areas  on  the  map.  Digitizing  tablets  are  available  with  drawing  space 
ranging  from  11x11  inches  to  48  x  60  inches. 


Limited  information  is  available  about  how  the  characteristics  of 
digitizing  tablets  impact  performance  (Ward  and  Phillips,  1987).  However, 
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empirical  research  does  indicate  that  the  maximum  acceptable  response  time 
from  input  of  coordinates  to  their  display  is  0.20  seconds  (Engle  and  Granda, 
1975). 

6.3.2  Data  Entry 

Data  entry  concerns  the  ways  the  user  should  be  able  to 
communicate  with  the  system  when  entering  data.  The  key  to  effective  data 
entry  is  to  reduce  the  amount  of  information  required  to  be  entered  by  the  user 
to  the  absolute  minimum.  The  system  can  predict  likely  data  values  and  the 
user  can  manipulate  auxiliary  input  devices  such  as  a  mouse  to  point  to  the 
desired  response  instead  of  requiring  the  user  to  type  the  full  response 
wherever  possible.  The  development  of  standard  templates  for  input  of 
commonly  occurring  information  greatly  speeds  data  entry  and  reduces  user 
errors.  These  templates  should  contain  clearly  indicated  default  values  for  the 
most  commonly  occurring  cases.  Data  entry  should  also  permit  natural 
expression  of  values  such  as  indicating  coordinate  information  using  the 
standard  grid  specification.  The  cues  or  prompts  for  data  entry  should  contain 
terminology  that  is  used  consistently  throughout  the  entire  system  and  the  use 
of  abbreviations  should  be  avoided. 

Whenever  the  user  completes  an  input,  the  system  should  provide 
immediate  feedback  and  not  leave  the  user  wondering  whether  or  not  his  entry 
has  been  received.  If  the  input  requires  extended  processing  that  will  not  be 
commensurate  with  the  user's  expectations  of  system  response,  an  indicator 
should  be  displayed  to  communicate  to  the  user  that  system  processing  is 
occurring. 


Users  will  make  errors  and  system  software  should  deal  appropriately 
with  incorrect  entries.  Not  only  should  they  incorrect  entry  be  clearly  indicated 
but  the  user  should  be  provided  with  explicit  guidance  on  what  actions  are 
required  and  how  to  abort  the  current  process.  The  human  factors  guidelines 
indicate  that  the  user  should  be  provided  with  immediate  feedback,  directional 
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guidance,  and  that  informative  messages  should  be  displayed  that  pinpoint  as 
close  as  possible  the  particular  user  entry  that  caused  the  error  (Morland, 
1983).  An  additional  consideration  is  to  require  confirmation  from  the  user 
before  performing  a  potentially  disastrous  operation  such  as  deleting  a  file  to 
occur.  The  user  should  be  able  to  cancel  the  operation  without  loss  of  data  and 
resume  the  current  processing  function. 


6.4  OUTPUT  CAPABILITIES 

To  fulfill  a  goal  for  effective  presentation  of  information  to  the  user,  the 
design  of  the  UCi  output  capabilities  and  features  must  minimize  the  effort 
required  by  the  user  to  scan,  perceive,  and  interpret  the  myriad  data  involved  in 
a  complex  arena  like  CE  functions. 


6.4.1  Screen  Layout 

Screen  format  and  content  concern  what  information  is  to  be  placed 
on  the  screen,  how  it  is  presented,  and  the  physical  layout  of  information 
appearing  on  the  display.  A  well-designed  screen  reflects  the  needs  of  its  user 
community  and  the  tasks  to  be  accomplished  via  use  of  the  system.  A  well- 
designed  interface  allows  the  user  to  place  everything  relevant  for 
accomplishing  a  particular  task  on  the  screen.  This  section  focuses  on  human 
considerations  in  screen  design  which  are  oriented  towards  simplicity, 
clarity,  and  understandability.  important  human  characteristics  to  be 
considered  in  screen  design  are: 


Perception  —  the  awareness  and  understanding  of  the 
elements  on  the  screen  which  help  establish  order  and 
meaning.  Eye  fixation  studies  indicate  that  initially  one's  eyes 
usually  move  to  the  upper  left  corner  of  the  display  and  then 
quickly  move  in  a  clockwise  direction.  During  and  following 
this  movement,  users  are  influenced  by  the  symmetrical 
balance  and  weight  of  the  titles,  graphics,  and  text  of  the 
display.  A  cluttered  or  unclear  screen  creates  the  requirement 
that  some  effort  must  be  expended  in  learning  and 
understanding  what  is  presented. 


6-12 


Memory  —  short-term  memory  is  highly  susceptible  to 
interference  and  its  contents  are  quickly  replaced  by  new 
information.  Its  capacity  is  about  seven  items  plus  or  minus  two 
(Miller,  1956).  An  important  memory  consideration,  with 
significant  implications  for  screen  design,  is  the  limited  ability  to 
recall  the  significance  of  many  colors  and/or  symbols. 

Learning  —  a  design  developed  with  the  intent  of  minimizing 
human  learning  time  can  accelerate  human  performance. 
Learning  can  be  enhanced  if  it  provides  complete  and  prompt 
feedback. 

Individual  Differences  —  the  design  must  permit  people 
with  widely  varying  skill  levels  to  satisfactorily  and  easily  learn 
to  use  the  system. 


One  of  the  biggest  problems  of  screen  display  design  arises  when  too 
much  information  is  put  on  the  screen  which  leads  to  user  confusion  and 
increased  error  rates.  Screens  should  provide  only  relevant  information 
because  the  more  information,  the  greater  the  competition  among  screen 
components  for  a  user’s  attention.  Visual  search  times  will  be  longer  and 
meaningful  patterns  more  difficult  to  perceive  if  the  screen  floods  a  person  with 
too  much  information.  Therefore,  only  information  relevant  to  the  user's  current 
need  should  be  displayed  and  the  user  should  be  able  to  selectively  control 
what  information  is  being  displayed  at  any  point  in  time  (Geiselman,  et  al,  1986, 
Brown,  1980).  The  user  should  be  able  to  control  what  information  is  on  the 
screen  through  such  features  as  scrolling  and  also  be  able  to  eliminate 
information  that  is  no  longer  of  interest  (Brown,  1980  and  Martin,  1973). 


The  layout  of  the  screen  should  be  structured  so  that  the  amount  of 
user  confusion  is  reduced.  The  user's  perception  of  the  structure  among  the 
different  areas  and/or  objects  on  the  screen  can  be  enhanced  by  the  careful 
and  consistent  use  of  a  variety  of  techniques  including  different  intensity  levels, 
colors,  numbers,  and  letters.  Specific  areas  of  the  screen  should  be  designated 
for  certain  kinds  of  information,  such  as  menu  options,  input  fields,  status 
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information,  etc.,  and  these  areas  should  be  maintained  consistently  on  all 
screens. 

6. 4.1.1  Windows.  One  of  the  most  popular  techniques  to  manage  the 
information  overflow  problems  of  screen  displays  is  the  use  of  windows. 
Windows  permit  the  simultaneously  display  of  two  or  more  sets  of  information 
on  a  single  display  screen.  Each  window  is  usually  (but  not  always)  delimited 
by  a  border  which  separates  it  from  the  rest  of  the  data  on  the  screen.  The 
major  benefit  of  the  capability  to  display  multiple  windows  on  a  display  screen  is 
the  reduction  of  the  load  placed  on  the  limited  cognitive  resources  of  users, 
particularly  short-term  memory.  Reducing  this  load  would  free  these  cognitive 
resources  for  other  tasks.  The  following  kinds  of  tasks  derive  the  most  benefit 
from  a  windowing  capability: 

•  The  display  of  supplemental  information  relevant  to  the  user's 
primary  task  —  e.g.,  help  messages.  Typically,  Help  messages 
result  in  a  totally  new  display  screen  overwriting  the  primary 
screen,  thereby  forcing  the  user  to  remember  the  situation 
requiring  assistance  (which  is  no  longer  displayed).  Similarly, 
the  user  must  remember  the  help  message  since  once  the  user 
returns  to  the  primary  task,  the  help  message  is  done. 
Alternatively,  Help  can  be  displayed  in  a  separate  window 
which  can  be  viewed  simultaneously  with  the  primary  screen. 

•  Monitoring  changes.  For  example,  the  user  can  modify  data  in 
one  window  and  then  have  the  result  immediately  reflected  in  a 
graph  displayed  in  another  window. 

6. 4.1. 2  Display  Features.  Contrasting  display  features  (e.g.,  different 
intensities  and  character  sizes,  blinking,  reverse  images,  color,  etc.)  can  be 
used  to  draw  attention  to  different  screen  components,  items  being  processed, 
and  urgent  items.  However,  these  features  should  be  used  in  moderation  since 
their  overuse  is  very  distracting  to  the  user.  Blinking  is  excellent  for  attention- 
attracting.  However,  it  reduces  legibility  and  is  distracting.  Its  use  should  be 
limited  to  situations  where  a  user  must  respond  quickly  and  it  should  be  turned 
off  as  soon  as  the  user  has  responded  (Smith  and  Goodwin,  1971).  It  is  aiso 
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recommended  that  instead  of  blinking  a  message  (which  will  make  the 
message  difficult  to  read),  an  adjacent  symbol  should  be  blinked  instead.  This 
would  assist  the  user  in  remembering  which  parameters  were  changed. 
Inverse  video  is  good  for  attention-getting  but  it  also  reduces  legibility.  It  should 
be  used  with  discretion  mainly  to  call  attention  to  errors  or  important  screen 
components.  Its  use  to  highlight  an  individual  item  as  it  is  selected  by  the  user, 
such  as  indicating  a  menu  selection,  provides  timely  and  accurate  feedback  to 
the  user  (Engel  and  Granda,  1975).  Inverse  video  is  recommended  for  error 
messages,  classification  markings,  indication  of  special  function  keys,  and 
menu  option  prompts. 

6. 4.1. 3  Typeface.  For  display  of  text,  the  use  of  both  upper  and  lower  case 
letters  assist  the  user's  perception.  Lower  case  fonts  with  initial  letter  in  upper 
cases  should  be  used  wherever  possible  because  this  format  provides  greater 
legibility  (Marcus,  1984).  Several  studies  have  found  that  regular-type  text  is 
read  significantly  faster  than  text  in  all  capitals  because  words  are  perceived  by 
the  shape  of  their  outline  and  not  deciphered  letter  by  letter  (Brown,  et  al., 
1980).  For  brief  captions,  labels,  and  prompts,  all  upper  case  can  be  used  for 
emphasis  but  should  be  used  sparingly  because  their  use  results  in  a  decrease 
in  reading  speed  by  as  much  as  13  percent  (Marcus,  1982).  The  font  size  of  the 
characters  should  be  at  minimum  7  by  9  pixels  (Vartabedian,  1971)  and  should 
use  a  single  typeface  such  as  Roman  or  Helvetica. 


6.4.2  US9, .Of  Color 

The  use  of  color  concerns  the  methods  used  for  making  consistent 
and  effective  use  of  color  for  differentiating  screen  components  and  as  an 
attention-getter.  The  use  of  color  can  assist  the  user  in  understanding  the 
logical  structure  of  the  data  on  the  screen.  As  a  visual  code,  it  can  assist  in 
giving  meaning  to  the  data  or  information  displayed,  the  differentiation  between 
required  and  optional  data,  and  the  indication  of  incorrect  responses.  However, 
color  must  be  used  carefully  because  its  use  alone  will  not  guarantee  improved 
performance  and  its  misuse  may  impair  performance  by  distracting  the  user  and 
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interfering  with  their  handling  of  information.  Since  the  use  of  color  is  attention- 
getting,  it  may  prove  distracting  to  the  user  who  may  notice  differences  in  color, 
regardless  of  whether  the  difference  has  any  meaning.  Users  also  tend  to 
visually  group  items  of  the  same  color  in  a  way  that  may  conflict  with  the 
intention  of  color  coding. 

The  human  eye  cannot  effectively  distinguish  more  than  eight  colors 
at  one  time.  In  general,  the  use  of  color  in  displays  should  be  limited  to 
between  five  and  seven  colors  (Murch,  1981).  This  is  based  upon  the  studies 
done  by  cognitive  scientists  demonstrating  that  humans  experience  great 
difficulty  in  maintaining  more  than  5-7  elements  simultaneously.  As  the  number 
of  colors  (in  a  display)  increases,  the  probability  of  confusion  among  colors  also 
increases.  The  cognitive  aspects  of  remembering  the  association  between  a 
particular  color  and  what  it  stands  for  also  increases  the  user's  workload  and,  in 
turn,  increases  the  utr.e  to  respond  to  a  specific  color.  Color  meanings  should 
also  be  consistent  with  the  user's  expectations  (e.g.,  red  means  danger). 
Another  rule  of  thumb  for  assigning  colors  to  display  features  is  to  avoid  the 
pairing  of  opponent  colors  such  as  red/green,  yellow/blue,  and  black/white. 
These  combinations  may  produce  afterimages  that  degrade  the  legibility  of 
other  items  on  the  display  (Durrett  and  Trezone,  1982). 


Another  factor  affecting  color  discrimination  is  the  environment  in 
which  the  system  is  to  be  used.  The  presence  of  artificial  or  natural  lighting  has 
an  effect  on  foreground-to-background  contrast.  Additionally,  as  illumination 
decreases  the  visibility  of  certain  colors  also  decreases.  Therefore  the  selection 
of  colors  should  be  based  on  the  luminance  levels  at  the  workstation. 

In  conclusion,  color  should  be  used  mainly  to  differentiate  screen 
components  and  fulfill  an  attention-getting  role.  If  each  color  is  to  communicate 
a  specific  significance,  then  the  number  of  colors  should  be  limited  to  about  6 
clearly  discriminable  colors.  Most  importantly,  the  use  of  color  must  be 
consistent  in  all  screen  displays.  Recommendations  for  the  use  of  color  for  the 
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UCI  are  ordered  so  that  bright  colors  emphasize  important  data  and  colors 
lacking  brightness  are  used  for  less  important  data. 


6.4.3  Graphics 

Interactive,  high-resoluticn  color  graphics  are  a  feasible  and  cost- 
effective  presentation  medium  for  CETOOLS  because  of  the  advancement  of 
computer  technology  that  permit  the  representation  of  data  in  a  graphic  form 
that  can  readily  be  stored,  manipulated,  and  displayed  by  computers. 
Advanced  graphics  facilities  can  considerably  enhance  the  communication 
between  the  user  and  the  system  by  providing  constant  visual  feedback  to 
provide  guidance  to  the  user  and  improve  the  overall  quality  of  the  system. 
Graphic  displays  not  only  provide  a  technique  for  presenting  data  but  also 
provide  a  mechanism  by  which  the  complexity  of  the  information  can  be 
reduced  by  making  interesting  data  points,  trends,  and  relationships  more 
apparent.  Several  research  studies  have  indicated  that: 

•  Spatial  and  visual  information  is  easier  to  remember  than 
verbal  and  textual  information  (White,  1983). 

•  Graphical  presentations  of  problem  data  and  solutions  result  in 
faster  perception  of  changes  from  previous  results  and  faster 
determination  of  problem  solutions  (Ives,  1982). 

Graphics  support  the  rapid  scanning  of  the  implications  of  a  course  of 
action  and  permit  rapid  identification  of  the  need  for  further  exploration. 

CETOOLS  will  involve  both  the  dynamic  and  static  display  of  graphic 
data.  A  major  problem  for  the  display  of  information  is  the  large  amounts  of 
potentially  relevant  data  that  must  be  examined  in  order  to  find  the  significant 
information  ror  the  users  current  problem  analysis.  Moreover,  what  is  relevant 
depends  on  what  the  CE  is  currently  doing,  which  could  change  overtime,  and 
what  the  user  is  currently  interested  in.  Graphic  representations  can  assist  this 
extraction  process  by  making  more  apparent  interesting  data  points,  trends,  and 
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relationships.  The  most  common  method  of  presenting  information  graphically 
uses  position  and  reference  shapes  (e.g.,  the  x  and  y  axes  of  a  graph)  to 
indicate  the  value  of  the  data  and  codes  (e.g.,  color,  label,  textures)  to  identify 
the  data.  Research  indicates  that  color  is  a  better  data  identifier  than  size, 
angle,  or  shape;  texture  codes  are  better  suited  for  distinguishing  the  display  of 
several  data  sets  on  a  combined  graph  (e.g.,  dotted/dashed  lines);  and  surface 
texture  is  useful  for  dividing  the  bars  of  a  bar  graph  into  their  component  parts 
(Morse,  1979). 

However,  graphics  must  be  used  carefully  to  prevent  cognitive 
overload  when  the  user  is  presented  with  complex  and  cluttered  graphical 
displays.  Determining  the  right  mix  of  text  and  graphics  is  another  area  where 
few  guidelines  are  available  for  the  interface  designer.  The  available 
guidelines  indicate  that  a  consistent  graphic  vocabulary  is  necessary  and  that 
legibility  and  readability  require  the  careful  use  of  color,  symbols,  and  typefaces 
(Marcus,  1982). 


6.5  USER., PROFILES 

Typically,  each  user  of  a  computer  system  develops  a  personal 
methodology  for  interconnecting  seemingly  isolated  techniques  and  strategies 
in  using  a  specific  system.  Over  time  the  user  develops  a  great  deal  of  problem- 
specific  declarative  and  procedural  knowledge  and  as  a  result  the  user 
becomes  proficient  in  operating  that  particular  system.  During  an  individual’s 
tenure  in  a  specific  position,  he  or  she  is  exposed  to  various  computer  systems. 
The  time  and  effort  spent  to  learn  a  new  system  can  be  significant.  The  learning 
phase  is  not  productive  and  can  be  considered  "lost"  time.  If  the  "time  to  learn" 
could  be  reduced  to  a  reasonably  short  amount  of  time,  the  "lost"  time  would  be 
negligible  and  the  user  would  be  able  to  benefit  more  quickly  from  the  system. 
Each  user  will  also  be  applying  the  system  to  the  needs  of  a  particular 
organizational  level.  A  CE  oriented  towards  the  developing  an  engineer  plan 
for  an  airborne  entity  will  probably  have  a  different  focus  than  a  person  oriented 
towards  land-based  entities.  Since  CETOOLS  will  be  applicable  to  all  CE’s,  it  is 
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important  for  it  to  include  a  capability  to  communicate  with  the  user  using  a 
unique  terminology  applicable  to  the  user's  needs.  For  these  reasons,  it  is 
recommended  that  CETOOLS  include  the  capability  to  construct  a  user  profile. 
The  user  profile  module  will  be  a  tool  designed  to  capture  user  preferences, 
store  them,  represent  them,  and  permit  the  user  to  interact  with  CETOOLS  in  a 
customized  manner  that  accommodates  that  particular  user's  knowledge  rather 
than  being  restricted  by  system  defined  commands  and  protocols. 

This  user  profile  capability  will  permit  a  computer  user  to  tailor  the 
CETOOLS  interface  by  allowing  the  user  to  specify  the  terms  used  for 
communicating  with  CETOOLS  using  his/her  particular  jargon.  This  tailoring 
tool  would  also  significantly  reduce  the  training  time  required  and  therefore 
reduce  the  cost  associated  with  training.  For  novice  users,  user  profiles  can 
assist  in  eliminating  computer  anxiety  so  that  the  individual  will  be  willing  to 
learn  a  new  system  rather  than  expend  time  and  effort  avoiding  it.  For  the 
expert  user,  it  will  allow  them  to  use  their  personal  preferences  in  constructing 
their  user  protocol  which  will  result  in  increased  productivity. 

Once  the  issues  that  need  to  be  addressed  to  initially  construct  the 
user  profile  have  been  resolved,  the  potential  techniques  employed  to  cause 
the  system  to  recognize  a  particular  user  and  then  load  the  user's  profile  into 
the  system’s  working  memory  will  need  to  be  explored.  Issues  concerning 
maintaining,  updating,  and  reconfiguring  a  user  profile,  once  it  has  been 
initialized,  will  require  investigation  with  regard  to  the  various  functions  of  the 
operating  systems,  the  issues  of  compatibility,  usability,  and  portability. 

There  are  a  few  techniques  currently  available  that  allow  a  user  to 
define  system  commands  through  the  use  of  personal  preference,  such  as 
macro  and  command  files.  However,  such  files  are  awkward  to  construct  and 
may  not  be  obvious  to  the  infrequent  or  inexperienced  user.  Since  many  users 
do  not  possess  a  programming  background,  a  criterion  level  of  understanding 
needs  to  be  established  and  then  the  degree  of  user  control  can  be 
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investigated.  In  addition,  other  variables,  such  as  hardware  limitations,  may 
affect  the  degree  of  user  freedom  possible,  and  therefore,  factors  such  as  these 
need  to  be  examined. 
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7.0  CETOOLS  SYSTEM 


The  primary  focus  of  CETOOLS  is  to  support  the  Combat  Engineer’s 
decision  making  process  and  provide  the  necessary  information  that  is  required 
to  develop  the  engineer  plan.  In  the  sections  which  follow,  the  high-level 
system  design  of  CETOOLS  will  be  presented,  the  major  system  modules 
described,  and  an  example  of  the  application  of  CETOOLS  to  a  hypothetical 
operational  situation. 


7.1  HIGH-LEVEL  DESIGN 

The  major  functional  components  of  CETOOL  are  presented  in  Figure 
7-1.  System  responsibilities  are  divided  between  these  software  modules  as 
follows: 


CONTROLLER  —  controls  activity  of  all  other  system 
components  and  directs  human-computer  interactions. 

DATA  MANAGER  —  manages  the  knowledge  ana  data 
bases. 

MEDIATOR  —  manages  all  human/computer  interface 
processes,  including  dialogue,  keyboard,  mouse,  and  digitizing 
inputs,  windowing,  graphics,  and  formatting  of  data  outputs. 

DECIDER  —  manages  decision  support  capabilities. 

DRAWER  —  manages  graphics  knowledge  and  display 
capabilities. 


Each  of  these  primary  modules  will  be  configured  independently  for  maximum 
system  flexibility.  For  example,  the  use  of  a  different  computer  display  system 
will  only  require  code  modification  to  MEDIATOR.  Likewise,  incorporating  a 
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new  data  or  knowledge  base  will  only  require  modification  to  DATA  MANAGER. 
This  approach  will  enhance  both  portability  and  the  flexibility  for  CETOOLS  to 
incorporate  changes  necessitated  by  the  dynamic  nature  of  the  CE  function, 
equipment,  and  methodology. 

With  the  exception  of  DRAWER,  the  components  of  CETOOLS  are 
clearly  feasible  in  the  microcomputer  environment.  Window,  graphics,  and 
mouse  interfaces  are  now  available  for  microcomputer  hardware  configurations. 
Data  base,  knowledge  base,  and  decision  support  systems  are  also  becoming 
commonplace.  However,  it  is  not  immediately  obvious  that  it  is  feasible  to 
develop  a  microcomputer-based  system  which  can  rapidly  respond  (i.e., 
seconds)  to  a  request  to  graphically  depict  a  situation  and  can  display  it  with  the 
necessary  resolution.  As  part  of  the  Phase  II  effort,  various  approaches  for 
generating  the  graphics  component  of  CETOOLS  will  be  developed  and 
evaluated. 


7.1.1  DECIDER 

In  developing  solutions  to  complex  problems,  it  is  generally 
necessary  to  develop  a  hybrid  system  that  combines  the  best  of  several 
techniques.  CETOOLS  will  incorporate  a  multiple-analysis  architecture  to 
support  decision  making  that  will  utilize  a  combination  of  algorithmic  and 
heuristic  techniques  since  it  is  doubtful  if  a  single  best  technique  can  be 
identified  that  would  provide  the  optimal  solution  for  all  cases.  The  DECIDER 
capabilities  will  incorporate  a  variety  of  techniques  based  upon  their  suitability 
both  for  providing  decision-aiding  support  to  the  Combat  Engineer  but  also  for 
their  ability  to  produce  accurate  results  within  a  reasonable  time  period. 
CETOOLS  differs  from  traditional  applications  of  artificial  intelligence,  decision- 
aids,  and  expert  systems  in  that  it  is  significantly  constrained  by  time;  by  the  fact 
that  it  must  operate  in  the  real  world  and  not  a  laboratory  where  specialized 
workstations  are  available  that  provide  very  sophisticated  computing  power  and 
interfaces;  by  the  dynamic  nature  of  real  world  situations  where  situation 
information  is  continually  changing;  and  by  the  demands  of  the  Combat 
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Engineer's  assignments  where  multiple  and  often-times  conflicting  tasks  are 
made  upon  the  available  time. 


It  should  be  apparent  that  CETOOLS  is  not  intended  to  simply  supply 
a  single  answer  to  a  single  question.  CETOOLS  is  a  workbench  environment 
for  the  Combat  Engineer.  The  CE  user  must  be  involved  in  the  analysis  process 
and  ultimately  make  the  decision  about  the  engineering  plan  for  a  mission  The 
system  provides  a  tool  to  support  the  decision  making  process  based  on 
historical  records,  standard  engineering  practices,  and  knowledge  base  rules 
about  the  planning  process.  The  system  will  have  more  knowledge  and  data 
available  than  any  single  Combat  Engineer  and  will  in  that  sense  be  a  superior 
DECIDER.  However,  the  system  will  only  capture  part  of  the  human  expertise 
involved  in  the  planning  process  and  must  therefore  be  provided  with  an 
interface  which  will  allow  it  to  function  as  part  of  a  human/machine  planning 
team. 


7.1.2  MEDIATOR 

Since  the  CETOOLS  interface  is  dependent  on  both  user 
characteristics  and  the  exact  nature  of  the  planning  process,  which  will  only  be 
specified  during  the  course  of  knowledge  engineering  in  a  Phase  II  effort,  it  is 
premature  to  present  an  interface  design  at  this  stage  of  development. 
However,  since  the  intent  is  to  rely  on  rapid  prototyping,  it  is  possible  to  present 
a  plausible  first-cut  configuration  which  could  be  constructed  quickly,  given  a 
reasonable  development  environment.  Traditional  applications  of  Al,  expert 
systems,  and  decision  support  systems  rarely  are  constrained  by  time 
requirements  and  typically  use  question  and  answer  dialogues  to  ascertain  the 
necessary  information.  CETOOLS  will  use  a  series  of  input  templates  to  obtain 
the  necessary  parameters  from  the  templates  and  the  UCI  will  be  tailored  to 
allow  the  Combat  Engineer  to  speedily  and  accurately  supply  this  information. 
The  CE  will  also  be  provided  with  the  capability  to  specify  necessary 
information  in  both  text  and  graphics  form  depending  upon  the  CE’s  particular 
view  of  the  optimal  method  for  his  data  entry  tasks.  The  time  constraint  in  which 
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the  CE  is  working  also  impacts  the  formats  in  which  the  results  are  displayed. 
The  results  of  any  analysis  must  be  presented  in  a  manner  that  facilitates  the 
ability  of  the  Combat  Engineer  to  rapidly  understand  the  results  and  to  quickly 
evaluate  multiple  inferences  and  options. 


Graphics  are  also  an  integral  part  of  the  CE's  decision-making 
process.  However,  the  overuse  of  graphics  tend  to  negatively  impact  the  ability 
of  a  user  to  quickly  infer  the  needed  information  from  a  display  and  result  in 
cognitive  overload.  Recent  studies  (e.g.,  Geiselman,  Landee-Thompson,  and 
Samet,  1986)  suggest  that  information  can  more  readily  be  assimilated  if  the 
information  is  split  into  logical  groups  and  the  user  is  provided  with  the  ability  to 
selectively  indicate  which  information  is  to  be  displayed  at  any  point  in  time. 
Therefore,  CETOOLS  will  provide  a  display  option  capability  to  permit  the  user 
to  control  the  contents  of  the  display. 

Section  7.2  illustrates  the  initial  design  of  the  user-computer  interface 
for  CETOOLS 

7.1.3  DATA  MANAGER 

The  DATA  MANAGER  module  will  control  access  to  all  system  data. 
The  representation  of  knowledge  is  the  heart  of  any  decision  support  system 
and  refers  to  employment  of  explicit  symbolic  representation  of  the  information 
in  its  domain  of  concern.  The  successful  operation  of  CETOOLS  requires 
several  information  components  including  combat  engineering  practices,  "rules 
of  thumb",  terrain  data,  OPFOR  knowledge,  user  knowledge,  etc.  In  order  to 
process  these  different  information  sources,  CETOOLS  will  include  both 
database  software  and  knowledge  base  software.  A  knowledge  base  is  distinct 
from  a  database  in  that  a  knowledge  base  represents  not  just  data  but  also 
representations  (e.g.,  rules)  that  use  the  data  as  a  basic  for  decision-making. 
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CETOOLS  databases  about  historical  OPFOR  data,  available 
resources,  and  geographical  data  wiil  utilize  standard  database  management 
technology.  The  attributes  required  to  characterize  this  data  can  easily  be 
arranged  in  table  format  with  rows  representing  components  and  columns 
representing  their  attributes.  This  structure  can  be  readily  accommodated  using 
standard  database  management  systems  (probably  of  the  relational  type).  The 
technology  driving  this  aspect  of  DATA  MANAGER  is  well  understood  and 
readily  available  in  "off-the-shelf"  software  packages. 

Combat  Engineer  knowledge,  operational  capability  knowledge,  and 
tactical  knowledge  require  a  totally  different  management  technique.  The 
knowledge  bases  will  contain  the  kind  of  information  required  by  CETOOLS 
concerning  engineering  "rules-of-thumb"  and  OPFOR  characteristics,  and  how 
that  information  needs  to  be  encoded.  The  knowledge  bases  will  also  contain 
information  concerning  the  user  which  wiil  be  required  for  user  profiling  and  the 
intelligent  dialog  aspects  of  the  system.  The  knowledge  scheme  developed  for 
CETOOLS  must  be  capable  of  representing  the  full  range  of  knowledge 
required  by  the  system,  be  easy  to  use,  and  provide  the  flexibility  to  be 
applicable  to  a  wide  variety  of  applications.  Research  in  knowledge-based 
systems  has  identified  several  major  types  of  knowledge  representation  (KR) 
techniques  which  are  summarized  below. 

7.1. 3.1  Procedural  Representation.  In  a  procedural  representation,  relevant 
knowledge  is  embodied  in  "procedures,"  i.e.,  subroutines  that  can  da  specific 
things  in  well-specified  situations.  Procedural  representations  have  the 
advantage  of  capturing  a  large  amount  of  knowledge,  including  heuristics, 
economically.  On  the  other  hand,  the  "big  picture"  may  be  lost  and  the 
underlying  knowledge  is  not  easily  retrievable  or  modifiable. 

7.1. 3. 2  Semantic  Nets.  A  semantic  net  represents  objects,  concepts,  and 
events  as  nodes  in  a  network,  and  the  interrelationships  between  them  as  links 
and  are  based  upon  the  concept  formulated  by  Woods  (1975).  The  nodes  can 
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be  linked  either  through  memberships  in  class  (the  Mis-a"  concept)  or  as  a  sub¬ 
property  of  another  node  (the  "has-a"  concept).  Semantic  nets  provide  a  very 
flexible  structure  and  additional  nodes  and  links  can  be  added  at  any  point. 
The  semantic  net  is  most  useful  to  represent  relationships  between  objects. 
The  "is-a"  and  "has-a"  relationships  permit  an  inheritance  capability  such  that 
any  characteristics  altered  in  an  node  can  be  automatically  carried  through 
another  node.  However,  a  major  problem  with  the  semantic  net  for  knowledge 
representation  is  that  a  given  net  may  have  several  interpretations  and  a  given 
meaning  may  be  reflected  in  several  different  nets. 

7. 1.3.3  Frames  and  Scripts.  Frames  and  scripts,  based  upon  the  ideas  on 
Minsky  (1975),  are  techniques  used  to  represent  the  sequence  of  events  and 
properties  that  typically  occur  in  a  given  situation  in  an  organized  fashion.  A 
frame  is  a  knowledge  representation  structure  in  which  new  data  is  interpreted 
in  terms  of  previous  experience.  A  frame  has  slots  to  represent  all  the  attributes 
of  interest.  Slots  can  contain  factual,  descriptive,  or  procedural  information. 
Slots  can  also  represent  another  frame  so  that  an  inheritance  hierarchy  is 
established  (i.e.,  lower  level  frames  inherit  knowledge  about  the  associated 
higher  level  frames).  Most  frame  techniques  for  knowledge  representation  also 
incorporate  provisions  for  generic  frames  to  be  established  for  various  object 
types.  Frames  have  the  capability  to  represent  a  great  complexity  of  information 
and  are  a  very  active  current  research  area.  Some  of  the  important  unresolved 
frame-related  issues  are  control  issues,  such  as  determining  the 
appropriateness  of  a  given  frame  and  selecting  a  second  frame  if  the  first  is  not 
appropriate. 

Scripts  may  be  viewed  as  a  special  class  of  frames  in  that  scripts 
embody  a  large  amount  of  previous  knowledge  in  "typical"  situation 
representations.  Scripts  are  specifically  designed  to  represent  knowledge 
about  events:  a  normal  or  default  sequence  is  represented  as  well  as  possible 
exceptions  or  errors.  As  with  frames,  there  are  procedural  attachments  with 
scripts. 
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7. 1.3. 4  Production  Rules.  Production  rule  knowledge  representation 
schemes  are  based  upon  conditional  statements  that  specify  an  action  that  is  to 
occur  under  a  certain  set  of  enabling  conditions.  The  rules  are  generally  stated 
as  two-part  statements  in  the  form:  "If  this  premise  is  true,  then  perform  this 
action  or  make  this  conclusion."  Each  rule  is  evaluated  and  when  the  current 
condition  matches  the  premise  stated  in  the  IF  rule  (i.e.,  the  condition  is  TRUE), 
then  the  indicated  action  is  performed.  Such  rules  permit  explanation  of  system 
conclusions  as  a  sequence  of  logical  steps.  Production  rule  techniques  are 
most  useful  for  presenting  procedural  knowledge,  i.e.,  methods  for 
accomplishing  goals.  Frequently,  production  rule  techniques  also  incorporate 
forward  and  backward  chaining  rules  and  a  pattern-matching  capability. 
Forward  chaining  matches  rules  against  facts  to  formulate  new  facts:  backward 
chaining  attempts  to  prove  a  new  rule  by  determining  what  facts  are  required. 
Pattern-matching  utilizes  complex  algorithms  to  formulate  decisions  based 
upon  the  best  match  to  current  conditions.  Rule-based  knowledge 
representation  techniques  have  become  dominant  in  current  expert  systems 
development.  However,  production  rules  become  unwieldy  and  difficult  to 
manage  as  the  number  of  rules  increase  since  rules  can  be  added  that  conflict 
with  previous  specified  rules. 

A  production  rule  system  is  the  probably  the  appropriate  form  of 
knowledge  representation  for  CETOOLS.  Such  a  system  can  easily  capture 
both  the  relationships  between  data  items  and  the  relationships  between  data 
and  required  actions.  Unlike  procedural  representation,  production  ruie 
representation  is  also  consistent  with  a  rapid  prototyping  approach  to 
development  since  a  rule  base  can  be  continuously  modified  in  an  efficient 
manner.  The  exact  combination  of  knowledge  representation  schemes  to  be 
used  for  CETOOLS  will  be  determined  as  part  of  the  Phase  II  effort. 

Information  encoded  for  use  by  DATA  MANAGER  will  derive  from 
several  sources.  System  knowledge  of  combat  engineering  heuristics  must  be 
incorporated  into  the  basic  structure  of  CETOOLS.  The  knowledge  itself  must 
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be  elicited  from  Combat  Engineer  experts  during  the  course  of  system 
development.  Historical  and  geographic  data  may  be  entered  by  users  as  part 
of  the  installation  process,  making  the  system  immediately  usable  for 
estimation,  or  built  up  over  time  by  the  entry  of  data.  Part  of  the  Phase  II  effort 
will  be  to  determine  the  attributes  that  will  be  required  by  the  DECIDER 
decision-aiding  process.  Profiling  information  is  specific  to  a  single  user,  but  it 
is  expected  that  the  acquisition  of  this  data  will  occur  during  system  use  and  be 
largely  transparent  to  the  user,  as  noted  in  the  discussion  of  MEDIATOR. 


7.1.4  CONTROLLER 

As  its  name  implies,  the  CONTROLLER  module  of  CETOOLS  will 
control  the  flow  of  information  between  the  MEDIATOR,  DECIDER,  DRAWER, 
and  DATA  MANAGER  modules.  It  will  decide  what  needs  to  be  done,  when  it 
will  be  done,  and  who  (what  module)  has  to  do  it.  All  interactions  between  the 
other  modules  will  flow  through  the  CONTROLLER;  this  will  facilitate  both 
system  implementation  and  system  enhancement  by  keeping  the  functions  of 
each  module  well  defined. 

CONTROLLER  will  have  the  same  basic  use  to  CETOOLS  that  an 
operating  system  has  to  a  computer  program;  it  will  control  all  of  the  aspects  of 
the  system,  while  allowing  the  other  modules  to  perform  their  own  functions.  It 
will  contain  the  access  paths  to  the  "overhead"  types  of  functions  that  each 
module  will  need,  either  y  directly  controlling  the  process  or  by  calling  on 
another  module  to  do  so.  This  design  strategy  will  enable  the  components  of 
CETOOLS  to  be  developed  separately  with  a  minimum  of  integration 
headaches  when  the  system  is  connected. 


7.1.5  DRAWER 

DRAWER  will  manage  the  presentatk  ;  of  graphics  information.  It  will 
be  developed,  as  much  as  possible,  to  be  device  independent  and  to  utilize 
software  based  upon  one  of  the  graphic  standards  such  as  Graphical  Kernel 
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System  (GKS)  which  is  the  proposed  ANSI  standard  for  interactive  two- 
dimensional  graphics.  DRAWER  will  be  designed  and  developed  so  that  it  can 
be  integrated  with  proposed  systems  that  will  be  available  in  the  future,  such  as 
the  Digital  Topographical  Support  System  (DTSS)  which  also  utilizes  GKS. 


7.2  CETOOLS  INTERACTIONS 

In  the  paragraphs  which  follow,  one  simple  interaction  sequence  is 
presented  which  integrates  many  of  the  interface  technology  options  discussed 
in  Section  6.  It  does  not  represent  a  final  design,  but  rather  a  potential  starting 
point.  Appendix  B  presents  a  first  cut  User-Computer  Interface  (UCI)  design 
specification  that  describes  in  detail  the  various  components  of  the  UCI.  The 
exact  nature  of  the  UCI  is  closely  coupled  to  the  particular  hardware  and 
software  environment  selected  for  implementation  of  CETOOLS.  The 
terminology  used  throughout  the  remainder  of  this  section  is  based  upon  the 
descriptions  of  the  UCI  components  described  in  Appendix  B.  The  example 
presented  in  this  section  illustrates  the  procedures  the  Combat  Engineer  would 
follow  in  order  to  develop  a  plan  for  the  operational  scenario  described  in 
Section  7.2.1. 

The  CETOOLS  user  dialogue  is  based  upon  the  concept  of  "selection 
not  entry"  where  the  user  is  presented  with  a  list  of  menu  or  input  template 
options  and  selects  the  desired  one  with  the  mouse  instead  of  keying  a 
command  name  or  character  string.  Since  the  user  is  always  presented  with  a 
list  of  the  available  choices,  the  user  is  not  required  to  remember  the  exact  set 
of  commands  or  syntax  available  nor  the  current  spelling  of  the  identifiers.  The 
experienced  user  will  be  provided  with  the  capability  to  override  the  use  of  the 
mouse  and  enter  desired  information  directly  from  the  keyboard  as  desired. 
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7.2.1  CETOOLS  Dialogues 

The  UCI  dialogue  consists  of  the  following  components: 

•.  Menu  Bar  —  a  list  of  available  options  displayed  on  a  line  at 
the  top  of  the  screen. 

•  Pull-Down  Menus  —  a  submenu  which  is  shown  in  a 
separate  window  displayed  beneath  the  menu  bar  containing 
the  list  of  commands  available  for  a  particular  selection  from 
the  menu  bar. 

•  Input  Templates  —  forms  containing  all  the  data  items  and 
clearly  indicated  default  values  required  to  specify  simulation 
data. 

•  Status  Bar  —  a  informatk  line  displayed  on  the  bottom  of 
the  screen  indicating  the  cu.ent  CETOOLS  functions  and  time 
information. 


These  items  are  described  in  more  detail  in  Appendix  B. 

When  the  user  first  enters  CETOOLS,  a  menu  bar  appears  at  the  top 
of  the  screen  (see  Figure  7-2).  The  UCI  closely  follows  the  Macintosh  style  of 
interface.  The  menu  bar  remains  in  place  throughout  a  session.  Control 
between  the  various  CETOOLS  modules  is  accomplished  through  the  options 
presented  on  the  menu  bar.  Menu-bar  selections  are  made  by  moving  the 
mouse  cursor  over  the  label  of  interest  and  holding  down  the  mouse  button.  A 
pull-down  menu  then  appears  in  a  box  drawn  in  a  separate  screen  window 
positioned  directly  beneath  the  title  of  the  selected  menu  bar  option.  The  pull¬ 
down  menu  contains  a  list  of  the  names  of  the  available  commands.  While 
holding  down  the  mouse  button,  the  user  moves  the  pointer  to  the  desired 
choice.  As  the  pointer  moves  to  each  option,  the  command  is  highlighted.  The 
command  that  is  highlighted  when  the  user  releases  the  mouse  button  is 
invoked,  and  the  pull-down  menu  window  disappears.  The  selected  command 
may  present  additional  menus  or  input  templates  or  perform  the  selected  task  if 
all  necessary  information  is  available.  These  submenus  present  only  a  short  list 


7-10 


of  the  commands  that  are  applicable  for  the  selected  operation  and  thereby 
avoid  confusing  the  user  with  massive,  largely  irrelevant  lists  of  possibilities 
The  pull-down  menu  lists  are  arranged  so  that  the  commands  are  arranged 
alphabetically.  Any  command  that  is  not  available  to  the  user  for  the  particular 
menu  option  at  the  current  time  is  shown  in  a  lighter  font,  and  the  user  is  not 
allowed  to  choose  them. 

The  menu  bar  also  contains  an  User  Aids  option  that  will  provide  the 
user  with  the  capability  to  obtain  guidance  and  help  messages  about  system 
usage  and  view/modify  basic  system  parameters  such  as  units  of  measurement 
(English  or  Metric),  time  (local  area,  objective  area,  or  zulu),  graphic  parameters 
(e.g.,  grid  size),  and  user  profiling  (e.g.,  color  coding).  It  also  provides  utility 
functions  to  review  and  modify  information  in  CETOOLS  data  bases. 

In  order  to  maximize  the  flexibility  of  the  system  and  provide  the  ability 
of  the  user  to  tailor  it  to  their  needs,  the  information  displayed  on  each  screen 
will  be  controlled  through  DATA  MANAGER  with  display  information  contained 
in  both  the  data  and  knowledge  bases  depending  upon  the  nature  of  the 
display.  For  example,  the  data  base  elements  used  to  define  equipment  may 
consist  of  the  following:  equipment  type,  authorized,  on-hand,  bumper  number, 
current  location,  and  weight.  Associated  with  each  element  will  be  a  flag  for 
each  display  associated  with  equipment  to  indicate  whether  that  piece  of 
information  should  be  included.  For  example,  these  elements  could  be  defined 
so  that  the  unit  status  display  includes  only  the  equipment  type,  authorized,  and 
on-hand  elements  while  the  marshalling  analysis  display  would  include 
equipment  type  and  location.  The  utility  command  provided  under  the  User 
Aids  option  would  allow  the  user  to  easily  access  these  flags  to  modify  the 
elements  to  be  included  for  a  particular  display.  This  type  of  capability 
alleviates  the  need  for  software  modification  whenever  the  user  information 
requirements  change  and  access  is  needed  to  different  types  of  information  that 
is  included  in  the  CETOOLS  knowledge  and  data  bases. 
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Input  templates  are  used  for  the  specification  of  a  group  of  related 
information.  They  are  mainly  used  for  supplying  additional  information  required 
before  a  system  command  can  be  processed.  The  following  techniques  are 
used  to  request  necessary  inputs: 


Check  Boxes  —  square  boxes  which  allow  the  user  to  check 
the  desired  attribute  options.  More  than  one  option  box  can  be 
checked  for  a  particular  attribute.  The  option  is  on  if  the  box  is 
checked;  otherwise  it  is  off.  The  check  boxes  appearing 
together  on  an  attribute  line  are  independent  of  each  other;  any 
number  of  them  can  be  off  and/or  on. 

Radio  Buttons  —  circles  which  force  the  user  to  select  only 
one  of  the  options  available  for  a  particular  attribute.  A  circle  is 
filled  in  with  a  smaller  black  circle  when  the  value  is  selected. 
Radio  buttons  occur  in  groups,  and  at  any  given  time,  only  one 
button  in  the  group  is  on.  Selecting  one  button  in  a  group 
automatically  turns  off  the  button  that  is  currently  on. 

Text  Entry  Boxes  —  rectangular  boxes  which  allow  the  user 
to  enter  textual  data  (numeric  or  alphanumeric),  with  the  size  of 
the  box  indicating  the  maximum  number  of  characters 
permitted. 


7.2.2  CETOOLS  Input  Devices 

The  CETOOLS  UCI  utilizes  three  input  devices: 


A  keyboard  to  enter  alphanumeric  text  and  numeric  data, 

A  mouse  to  specify  menu  options,  controlling  the  cursor, 
selecting  information,  manipulating  graphic  information,  and 
specifying  insertion  points,  and 

A  graphics  tablet  to  enter  graphic  information  such  as  terrain 
features. 


The  user  controls  which  of  these  input  devices  is  used  at  any  point  in  time.  For 
example,  to  specify  graphic  information,  either  the  mouse  or  the  graphics  tablet 
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can  be  utilized.  However,  the  use  of  the  graphics  tablet  provides  more 
precision.  It  is  up  to  the  user  to  decide  which  device  is  appropriate  for  the  task 
at  hand. 


7.2.3  CETOOLS  Usage 

An  overview  of  the  CE  planning  process  is  illustrated  in  Figure  7-3 
with  the  functions  to  be  provided  by  CETOOLS  distinguished  by  a  gray 
background.  A  hierarchical  task  decomposition  analysis  was  performed  to 
identify  the  functional  groupings  required  for  CETOOLS  in  order  to  provide  a 
structure  for  the  planning  process.  The  CETOOLS  menu  bar  contains  an  entry 
for  each  of  the  major  system  functions  as  described  below: 


Mission  —  defines  the  mission  objectives. 

Unit  Status  —  supplied  information  about  the  assets 
available  to  the  unit . 

Terrain  —  defines  terrain  information. 

Plans  —  develops  and  refines  all  aspects  of  the  engineering 
plan. 

Analysis  —  evaluates  the  developed  plans  and  indicates  any 
problems. 

Reports  —  generates  the  reports  required  to  present  and 
implement  the  plan. 

Displays  —  specifies  the  type  of  graphical  representations  to 
be  included  on  the  display. 

User  Aids  —  provides  the  ability  to  change  basic  system 
parameters  such  as  measurement  units,  time  format,  define 
map  features  such  as  grid  spacing,  print  selected  information, 
obtain  additional  help,  and  set  system  parameters. 
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Figure  7-3.  CE  Planning  Process 


Logistics 

Operations 


•  Files  —  provides  general  system  features  such  as  indicating 
which  data  and  knowledge  bases  are  to  be  used,  defining 
output  medium  and  parameters,  and  terminating  CETOOLS. 

7.3  CETOOLS  EXAMPLE 

This  section  illustrates  how  the  ABE  could  use  CETOOLS  to  develop 
an  engineering  plan  for  a  hypothetical  operational  scenario.  The  following 
discussion  suggests  the  general  approaches  that  will  be  used  to  develop  the 
engineer  plan  but  the  exact  details  of  the  techniques  to  be  used  will  be 
developed  as  part  of  the  Phase  II  effort. 


7.3.1  Operational  Scenario 

Forces  of  the  radical  Islamic  regime  of  Amiran  are  massing  along  the 
border  of  the  strategically  important  US  ally,  Dromar.  Amiran  has  long  been 
supporting  the  Islamic  Revolutionary  Front  (IRF),  a  guerilla  movement  in  the 
north  of  Dromar.  Recently,  Dromarian  forces  began  an  offensive  against  the 
guetflias  which  has  been  highly  successful  and  has  threatened  the  IRF  with 
complete  annihilation.  In  a  show  of  support  for  the  IRF,  the  government  of 
Amiran  has  brought  its  forces  to  full  alert  and  has  positioned  some  within  five 
kilometers  of  the  border.  Dromarian  forces  are  both  qualitatively  and 
quantitatively  inferior  to  those  of  Amiran  and  have  therefore  requested  US 
support. 


The  National  Command  Authority  has  decided  to  commit  US  ground 
forces  to  the  region  in  a  show  of  force  designed  to  intimidate  Amiran  and,  if 
necessary,  prevent  them  from  seizing  control  of  the  Dromarian  oil  fields.  The 
JCS  warning  order  was  issued  at  0930  13  May.  At  0300  15  May,  a  "redline" 
message  alerted  all  units  in  the  82nd  Airborne  Division  at  Fort  Bragg,  North 
Carolina.  The  division  ready  brigade  (DRB)  was  the  3rd  Brigade  (505th 
Airborne  Infantry  Regiment)  support  by  C  Company  of  the  307th  Engineer 
Battalion.  The  following  scenario  depicts  the  complex  series  of  interactions  that 
occur  when  planning  engineer  support  to  an  airborne  operation. 


7-14 


Key  leaders  from  the  division  assemble  at  Division  headquarters  to 
receive  a  mission  and  situation  briefing  from  the  Commanding  general  and  his 
staff.  Among  these  key  leaders  are  the  commander  of  the  307th  and  the 
Assistant  Division  Engineer.  The  Assistant  Brigade  Engineer  (Company 
Commander  for  C  Company)  does  not  attend  this  initial  briefing,  but  reports  to 
the  3rd  Brigade  headquarters  and  reports  that  the  engineer  company  is  100% 
assembled.  At  N  +  2:30,  the  3rd  Brigade  commander  and  his  staff  assemble  at 
the  Brigade  headquarters  to  develop  the  ground  tactical  plan.  This  process  is 
simultaneously  occurring  at  the  DRF1 ,  DRF2,  and  the  DRF3.  The  mission  of  the 
3rd  Brigade  is  stated  as  follows: 

"3rd  Brigade  will  conduct  a  parachute  assault  in  the  vicinity  of  Nawa 
(BS2343),  secure  the  airstrip  for  follow-on  echelons,  linkup  with 
Dromarian  government  forces,  and  establish  defensive  positions 
along  the  Northwest  -  Southeast  road  in  zone." 


7.3.2  Mission  Definition 

Once  the  mission  has  been  received,  the  ABE  must  now  interact  with 
each  of  the  staff  sections  to  extract  information  necessary  for  developing  his 
contribution  to  ground  tactical  plan.  The  ABE  must  have  the  plan  completed 
and  approved  by  N  +  6:30.  The  ABE  will  first  define  the  basic  parameters  of  the 
mission  by  utilizing  the  Mission  option  including  the  definition  of  the  various 
mission  phases.  The  characteristics  of  the  opposing  forces  and  anticipated  US 
response  would  be  obtained  from  the  responsible  staff  member.  The  pull-down 
menu  that  contains  the  commands  associated  with  Mission  is  illustrated  in 
Figure  7-2.  To  select  one  of  the  options  (e.g.,  "Define"),  the  user  places  the 
arrow-shaped  mouse  cursor  over  the  "Mission"  label  in  the  menu-bar, 
depresses  the  mouse  button  ("clicking"),  and  selects  "Define"  from  the  pull¬ 
down  menu  which  appears.  The  user  can  selectively  move  between  these 
options  and  select  them  at  any  point  during  the  session.  This  would  allow  the 
user  to  broadly  outline  the  mission  early  in  the  planning  process  and  then  return 
to  refine  the  information  as  more  details  and  intelligence  becomes  available. 
Mission  contains  the  following  commands: 
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Area  of  Operation  —  allows  the  user  to  define  the 
parameters  associated  with  the  geographical  area  assigned 
as  the  area  of  operation  (AO). 

Define  —  allows  the  user  to  define  the  mission  phases,  tasks, 
time,  location,  and  indicate  the  type  of  engineering  support 
required.  The  information  required  to  define  this  information 
will  be  a  dialog  window  as  illustrated  in  Figure  7-4.  The  input 
template  contains  text  entry  boxes  for  entering  the  phase  and 
task  numbers,  start  and  complete  time,  grid  coordinates,  and 
phase  description.  ABE  support  is  specified  using  check  boxes 
with  the  entry  of  an  X  indicating  that  the  item  is  selected.  The 
user  moves  the  cursor  to  anywhere  within  area  defined  by  the 
box  and  its  associated  legend  to  the  right  and  clicks.  If  the  box 
will  previously  blank,  an  X  will  appear.  As  shown  in  Figure  7-4, 
the  first  phase  of  the  mission  is  the  parachute  assault  and  no 
engineering  support  is  required.  The  None  box  is  checked  to 
indicate  that  the  ABE  reviewed  the  tasks  and  decided  that  no 
support  was  required.  The  user  clicks  in  the  Next  pushbutton 
to  indicate  that  an  additional  phase/task  is  to  be  defined  and 
clicks  in  the  OK  pushbutton  to  close  the  define  window. 

Drop  Zone  —  allows  the  user  to  define  the  parameters 
associated  with  the  drop  zone  (DZ)  area  upon  which  airborne 
troops,  equipment,  and  supplied  will  be  air-dropped. 

FFOR  —  allows  the  user  to  define  the  friendly  forces.  The 
input  template  for  defining  friendly  forces  is  illustrated  in  Figure 
7-5.  The  selection  of  the  unit  to  perform  a  particular  task  is 
accomplished  through  the  use  of  radio  buttons.  The  black  dot 
in  the  middle  of  the  circle  indicates  the  current  selection.  The 
dot  can  appear  in  only  one  of  the  options  available  to  the  user 
on  an  input  line.  For  example,  only  one  of  the  brigades  can  be 
selected  at  a  time.  CETOOLS  provides  a  hierarchical 
capability  for  unit  selection.  That  is,  if  a  brigade  and  battalion 
are  specified,  all  associated  companies,  platoons,  and  squads 
are  selected. 

Landing  Area  —  allows  the  user  to  define  the  parameters 
associated  with  the  landing  area. 
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Figure  7-4.  Mission  -  Define  Screen 
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Figure  7-5.  Mission  -  Friendly  Forces 


OPFOR  —  allows  the  user  to  define  the  opposing  forces.  The 
user  will  be  provided  with  the  ability  to  select  standard 
templates  that  represent  various  opposing  forces.  The  screen 
illustrated  in  Figure  7-6  illustrates  the  selection  of  the  Amiran 
rifle  regiment  template.  The  user  can  also  indicate  the  map 
display  option  so  that  the  template  will  be  placed  on  the  map. 
The  user  can  then  use  the  mouse  to  select  the  OPFOR 
template  and  move  it  to  the  appropriate  location  and  rescale 
and  orient  the  template  as  appropriate.  The  icons  on  the  left 
side  of  the  screen  can  also  be  used  to  add  additional  elements 
that  were  not  contained  in  the  standard  template.  The 
components  of  the  template  can  also  be  rearranged  by  using 
the  mouse  to  click  on  a  unit  and  dragging  it  to  a  new  location 
on  the  map  grid. 


7.3.3  Unit  Status 

The  ABE  then  accesses  the  system  to  review  the  status  of  his 
personnel  and  resources.  In  order  to  review  current  unit  status,  the  user  would 
select  the  Unit  Status  option  from  the  menu  bar.  The  pull-down  menu  that 
contains  the  commands  associate  with  Unit  Status  is  illustrated  in  Figure  7-7. 
The  status  template  contains  a  time  parameter  that  can  be  used  to  indicate  the 
particular  time  for  which  the  status  information  is  desired.  For  example,  both  the 
current  status  plus  the  estimated  status  of  assets  at  time  N  +  18  may  be 
requested.  Unit  Status  contains  the  following  commands: 

•  Aircraft  —  allows  the  user  to  obtain  information  about 
available  aircraft . 

•  Class  III  —  allows  the  user  to  obtain  information  about 
available  petroleum,  oils,  and  lubricants  (POL). 

•  Class  IV  —  allows  the  user  to  obtain  information  about 
construction  and  barrier  materials. 

•  Class  V  —  allows  the  user  to  obtain  information  about 
ammunition. 
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Figure  7-6.  OPFOR  Display  Screen 
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Figure  7-7.  Unit  Status  Pull  -  Down  Menu 


Equipment  —  allows  the  user  to  obtain  information  about 
equipment  as  illustrated  in  Figure  7-8.  The  top  portion  of  the 
screen  contains  the  window  to  specify  time  and  unit.  The  unit 
information  is  available  hierarchically.  The  authorized  and  on- 
hand  information  for  each  piece  of  equipment  assigned  to  the 
selected  unit  is  displayed  along  with  a  difference  column. 
Negative  differences  will  be  displayed  in  red  (shown  as  bold 
typeface  in  the  figure). 

Personnel  —  allows  the  user  to  obtain  information  about 
personnel  as  illustrated  in  Figure  7-9  The  top  portion  of  the 
screen  contains  the  window  to  specify  time  and  unit.  The  unit 
information  is  available  hierarchically.  The  authorized  and  on- 
hand  information  for  personnel  assigned  to  the  selected  unit  is 
displayed  along  with  a  difference  column.  Negative 
differences  will  be  displayed  in  red  (shown  as  bold  typeface  in 
the  figure). 


7.3.4  Terrain  Specification 

The  next  step  is  for  the  ABE  to  confer  with  the  S2  on  the  terrain  to  be 
found  at  the  objective  area,  determine  the  status  of  the  airfield  at  Nawa,  and 
identify  key  terrain  and  avenues  of  approach.  The  S2  provides  the  ABE  with  the 
following  terrain  intelligence: 


1.  Hills  710  (BS2045)  and  635  (BS2345)  dominate  the  highway 
approach  into  the  area  of  operations  (AO)  from  the  northwest, 
hill  630  (BS2721 )  dominates  the  highway  approach  into  the 
AO  from  the  southeast  as  well  as  cross-country  approaches 
from  the  east  and  south.  Hills  607  (BS2546),  612  (BS2645), 
and  629  (BS2843)  provide  long-range  observation  and  direct 
fire  to  the  north  and  east  of  the  AO. 

2.  The  area  iying  generally  east  of  Hills  710  and  635  is  primarily 
cultivated  and  interspersed  with  scattered  clusters  of  boulders. 
Cultivated  fields  are  frequently  divided  by  low  rows  of  rocks 
that  local  farmers  have  cleared  from  their  fields.  These  rows  of 
rocks  are  irregular  in  form  and  length  but  will  provide  cover 
from  flat-trajectory  fire. 
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Figure  7-8.  Unit  Status  -  Equipment  Screen 


Unit  Status  -  Personnel _ BIBfla  Time:  N+2:40  111440.0QZ  " 
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3.  Old  lava  formations  on  and  in  the  vicinity  of  hills  630,  607,  and 
612  restrict  tracked  and  wheeled  vehicle  movement  and 
provide  excellent  cover  from  flat-trajectory  fire. 

4.  The  streambeds  that  run  generally  north-south  (BS2652— - 
BS3241  and  BS3350— BS3241— BS2329)  are  normally  dry 
and  fordable.  The  steep  banks  and  old  lava  formations  along 
these  streambeds  restrict  east-west  vehicular  movement  to  a 
few  existing  crossing  sites. 

5.  The  marsh  in  the  vicinity  of  BS2554  will  not  support  heavy 
vehicle  traffic. 

6.  The  area  generally  west  of  Hills  710  and  635  is  slightly  rolling 
with  numerous  shallow  dry  gullies  and  old  lava  formations 
consisting  of  many  large  and  moderate-size  boulders.  Cross¬ 
country  vehicular  movement  is  possible  in  these  areas  with 
moderate-to-extreme  difficulty.  The  streambeds  that  run 
generally  north-south  from  BS8051 — BS7332  are  normally  dry. 
The  steep  banks  and  old  lava  formations  along  the  banks 
restrict  east-west  vehicular  movement.  Numerous  depressions 
and  hummocks  north  and  west  of  Hill  635,  combined  with  old 
lava  formations  in  the  area,  make  vehicular  cross-country 
movement  slow  and  extremely  difficult. 

7.  Observation  and  direct  fire  are  excellent  from  the  hills  in  the 
AO.  Cover  from  flat-trajectory  weapons  is  excellent  in  the  old 
lava  formations  and  numerous  clusters  of  boulders  throughout 
the  area.  Concealment  is  fair  throughout  the  area.  The  major 
northwest-southeast  highway  provides  the  high-speed 
approaches  into  the  AO.  Cross-country  movement  of  vehicles 
through  cultivated  areas  of  the  AO  is  good  and  is  impeded  only 
by  occasional  clusters  of  boulders  and  low  rows  of  rocks 
separating  cultivated  fields. 

8.  The  village  of  NAWA  (BS2343)  is  populated  by  an  estimated 
200  to  300  people  who  remained  behind  when  their  village 
was  overrun  by  IRF  forces.  They  are  expected  to  be  passive 
and  cooperate  with  US  forces  when  the  airborne  assault 
begins.  Buildings  are  generally  one-story  dwellings 
constructed  of  rock  and  mud  bricks. 

9.  Sufficient  drop  zones  are  available  in  the  area.  Landing  zones 
are  restricted  to  the  major  highway  running  through  the  AO. 
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10.  The  airfield  east  of  Nawa  (BS2443)  is  an  unimproved  C-130 
capable  airstrip.  Imagery  indicates  that  recent  fighting  in  the 
area  has  damaged  the  airstrip. 


The  S2  provides  the  ABE  with  the  following  weather  and  climate 
intelligence: 

1.  Climate  —  Dromar  has  essentially  a  two-season  climate: 
winter  lasts  from  November  through  April  and  summer  lasts 
from  May  through  October.  Precipitation  from  June  through 
September  is  negligible. 

2.  Temperature  —  Temperatures  for  the  period  of  the  airborne 
operation  will  range  from  a  daily  high  in  the  nineties  and  low 
hundreds  to  a  daily  low  in  the  sixties. 

3.  Prevailing  Winds  —  Westerly  winds  are  persistent  much  of 
the  year.  The  average  windspeed  during  the  period  of 
operation  is  9  knots.  Winds  generally  reach  their  maximum 
speeds  in  midafternoon  with  calm  winds  prevailing  in  the  early 
morning  and  early  evening  hours. 

4.  Light  Data  —  The  light  table  is  shown  below: 
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In  order  to  specify  terrain  and  weather  information  obtained  from  the 
S2,  the  ABE  would  select  the  Terrain  option  from  the  menu  bar.  The  pull-down 
menu  that  contains  the  commands  associate  with  Terrain  is  illustrated  in  Figure 
7-10.  Terrain  contains  the  following  commands: 


Avenue  of  Approach  —  allows  the  user  to  specify 
parameters  about  the  avenue  of  approach.  Figure  7-1 1 
illustrates  the  screen  after  the  user  has  defined  the  avenues  of 
approach  and  the  slow/no-go  areas.  The  icons  on  the  left  side 
of  the  screen  were  used  to  specify  these  areas.  The  icons  are 
used  to  create  objects  that  represent  key  features.  Each  object 
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Figure  7-1 1 .  Display  Terrain  With  Avenues  of  Approach 


is  an  independent  item  that  is  stored  in  a  CETOOLS  data 
bases.  Associated  with  each  object  is  a  set  of  characteristics 
that  define  the  features  of  the  object  such  as  size,  location,  etc. 
To  select  one  of  the  icons,  the  mouse  is  used  to  click  on  the 
desired  icon.  Then  the  mouse  is  moved  to  the  point  on  the 
map  where  the  corner  of  the  object  is  to  be  placed.  The  mouse 
button  is  again  clicked  and  the  user  sketches  the  desired 
shape  and  clicks  on  the  beginning  point  of  the  shape 
automatically  closes  the  shaped  and  stops  the  definition 
procedure  for  the  object.  This  process  would  be  repeated  until 
all  information  has  been  specified. 


Climate  —  allows  the  user  to  specify  parameters  about  the 
climate. 

Cover  and  Concealment  —  allows  the  user  to  specify 
parameters  that  affect  cover  and  concealment.  . 

Key  Terrain  —  allows  the  user  to  specify  parameters  about 
the  key  terrain  features.  Figure  7-12  illustrates  the  screen  after 
the  user  has  defined  key  terrain  features.  The  icons  on  the  left 
side  of  the  screen  were  used  to  specify  key  features  as 
described  above.  If  the  object  requires  additional  information, 
such  as  the  highest  elevation  point  for  hills,  an  input  template 
window  will  be  displayed  for  the  user  to  enter  the  necessary 
data. 

Observation/Fields  of  Fire  —  allows  the  user  to  specify 
parameters  that  relate  to  observation  and  fields  of  fire. 

Obstacles  —  allows  the  user  to  specify  parameters  about 
existing  obstacles. 

Weather  —  allows  the  user  to  specify  parameters  about  the 
weather.  Figure  7-13  illustrates  the  input  template  for  the  entry 
of  weather  information.  Text  entry  boxes  are  shown  for  each 
field  of  information  associated  with  weather. 

Other  —  allows  the  user  to  specify  other  information  which 
could  impact  the  engineer’s  plan. 
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Figure  7-13.  Terrain  Weather  Screen 


7.3.5  Plan  Development 

Having  specified  the  available  information  from  the  various  staff 
members,  the  ABE  will  next  initiate  the  process  of  sketching  out  a  rudimentary 
engineering  plan.  As  part  of  the  development  of  the  engineering  plan,  he  will 
decide  how  to  best  integrate  it  with  the  ground  tactical  plan  and  evaluate 
various  alternatives.  As  the  ABE  receives  newer  information  from  the  various 
staff  members,  for  example,  the  operation  plan  from  the  S3;  he  can  explore 
different  options  for  emplacing  obstacles  to  support  the  anti-armor  defense. 


The  Plan  option  on  the  menu  bar  contains  a  list  of  the  plans  that  the 
engineer  can  develop.  Any  or  ail  of  the  plans  may  be  chosen  and  the  planning 
options  can  be  selected  in  any  order.  The  pull-down  menu  that  contains  the 
commands  associated  with  Plan  is  illustrated  in  Figure  7-14  and  contains  the 
following  commands: 


Airfield  Repair  —  is  used  to  generate  the  plan  required  for 
airfield  repair. 

Air  Movement  —  is  used  to  generate  the  air  movement  plan. 

Countermobility  —  is  used  to  generate  the  countermobility 
plan.  Figure  7-15  illustrates  the  screen  after  the  user  has 
defined  the  initial  set  of  obstacles  using  the  icons  on  the  left 
side  of  the  screen  to  specify  key  features  as  described  above. 
If  the  object  requires  additional  information,  such  as  details  of 
an  obstacle  and  personnel/equipment  assignments,  an  input 
template  window  will  be  displayed  for  the  user  to  enter  the 
necessary  data.  This  is  illustrated  in  Figure  7-16  for  obstacle 
307XP3001 ,  a  strip  mine  field.  The  personnel  assignment 
portion  of  the  input  template  would  be  used  by  the  ABE  to 
indicate  which  unit  is  to  emplace  the  indicated  obstacle.  The 
specifications  are  attached  to  the  object  so  that  the  user  can 
also  review  and/or  modify  this  information  about  a  particular 
object  at  any  point  in  time  by  clicking  on  the  object. 

Echelonment  &  Landing  —  is  used  to  generate  the 
echelonment  and  landing  plan. 
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Figure  7-15.  Display  -  Map/Obstacles/Terrains 


General  Engineering  —  is  used  to  generate  the  plan 
required  for  general  engineering  tasks. 

Marshalling  —  is  used  to  generate  the  marshalling  plan. 

Mobility  —  is  used  to  generate  the  mobility  plan. 

Survivability  —  is  used  to  generate  the  survivability  plan. 


7.3.6  Plan  ..Analysis 

Having  formulated  his  tentative  plan,  the  ABE  can  now  begin  the 
process  of  evaluating  the  impact  of  the  plan  on  various  requirements  such  as 
the  availability  of  needed  resources  (e.g.,  weight  of  equipment,  fuel 
consumption  requirements,  etc.)  and  the  amount  of  time  required  to  implement 
the  plan.  The  Analysis  option  from  the  menu  bar  is  then  used  to  analyze  the 
plans  from  various  perspectives,  e.g.,  personnel  usage.  Each  analysis  will  be 
displayed  in  a  separate  window  so  that  the  ABE  user  can  view  more  than  one 
piece  of  information  at  a  time.  Similarly,  the  Unit  Status  information  can  also  be 
displayed  in  windows  so  that  the  ABE  could  have  current  unit  status  information 
for  personnel  displayed  simultaneously  with  personnel  usage  for  the  developed 
plans.  This  capability  allows  the  ABE  to  predict  the  expenditure  of  resources  for 
any  given  countermobility  plan  thereby  allowing  him  to  establish  priorities  and 
logistics  requirements. 

The  pull-down  menu  that  contains  the  commands  associated  with 
Analysis  is  illustrated  in  Figure  7-17  which  contains  the  following  commands: 

•  Class  III  —  allows  the  user  to  analyze  POL  usage. 

•  Class  IV  —  allows  the  user  to  analyze  the  construction 
material  usage. 

•  Class  V  —  allows  the  user  to  analyze  ammunition  usage. 
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Figure  7-17.  Analysis  Pull-Down  Menus 


Equipment  —  allows  the  user  to  obtain  analyze  equipment 
usage  as  illustrated  in  Figure  7-18.  It  displays  all  the 
equipment  that  has  been  identified  as  being  used  for  one  of  the 
defined  plans  along  with  identifier  information  such  as  obstacle 
number.  It  displays  the  quantity  and  time  required  along  with 
the  time  the  equipment  asset  is  needed.  If  CETOOLS  detects 
any  conflicts,  they  will  be  shown  in  red  (bold  typeface  in  Figure 
7-18).  For  example,  the  plan  requires  the  use  of  2-1  1/4  Cargo 
Trucks  at  H+2:00.  However,  the  current  unit  status  for 
equipment  indicates  that  only  1  of  these  trucks  is  available.  In 
order  to  resolve  this  conflict,  the  ABE  can  change  the  entries  in 
any  column  and  the  resource  information  will  be  updated 
accordingly.  In  this  case,  another  vehicle  could  be  substituted 
or  the  start  time  for  the  use  of  the  vehicle  modified. 

Location  —  allows  the  user  to  analyze  where  key 
components  of  the  plan  are  located  are  various  points  in  time. 

Marshalling  —  allows  the  user  to  analyze  the  marshalling 
plan. 

Personnel  —  allows  the  user  to  analyze  personnel  usage  for 
the  various  plans  as  illustrated  in  Figure  7-19.  The  screen 
indicates  that  conflict  exists  since  the  1st  platoon  of  the  1st 
squad  is  assigned  to  two  different  tasks  that  are  to  begin  at  the 
same  time.  Again,  if  any  conflicts  are  detected,  they  would  be 
displayed  in  a  distinctive  color. 

Task  Priority  —  allows  the  user  to  analyze  defined  tasks  and 
their  usage  requirements. 

Time  —  allows  the  user  to  analyze  the  plans  from  a  time 
perspective. 

Weight  —  allows  the  user  to  analyze  weight  usage. 


7.3.7  Plan-Reports 

The  ABE  must  now  brief  other  staff  members  on  the  engineering 
portion  of  the  OPLAN.  The  Report  option  from  the  menu  bar  is  used  to  develop 
these  reports.  Each  report  will  be  displayed  in  a  separate  window  so  that  the 
ABE  user  can  view  more  than  one  piece  of  information  at  a  time.  The  reports 
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sis  -  Personnel  Screen 


can  be  previewed  on  the  screen  and,  in  addition,  hard  copies  can  be 
generated.  The  pull-down  menu  that  contains  the  commands  associated  with 
Report  is  illustrated  in  Figure  7-20  which  contains  the  following  commands: 


Class  III  —  allows  the  user  to  report  POL  usage. 

Class  IV  —  allows  the  user  to  report  the  construction  material 
requirements. 

Class  V  —  allows  the  user  to  report  ammunition  requirements. 

Equipment  —  allows  the  user  to  obtain  report  equipment 
requirements. 

Location  —  allows  the  user  to  report  where  key  components 
of  the  plan  are  to  be  located  are  various  points  in  time. 

Marshalling  —  allows  the  user  to  report  the  marshalling  plan 
as  illustrated  in  Figure  7-21.  The  entries,  U/K  and  TBD, 
indicate  information  that  has  not  yet  been  supplied. 

Orders  —  allows  the  user  to  report  the  engineer  part  of  the 
orders. 

Personnel  —  allows  the  user  to  report  personnel  usage  for 
the  various  plans 

Task  Priority  —  allows  the  user  to  analyze  defined  tasks  and 
their  usage  requirements. 

Time  —  allows  the  user  to  generate  timeline  reports. 

Weight  —  allows  the  user  to  report  weight  usage. 


7.3.8  Display  Potions 

Graphics  provide  an  effective  technique  for  quickly  absorbing  critical 
information  and  presenting  information  to  other  staff  members.  However,  they 
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must  be  used  judiciously  to  avoid  overloading  the  CE's  cognitive  capabilities 
with  a  cluttered  screen.  Since  each  type  of  display,  i.e.,  map,  terrain,  OPFOR, 
FFOR,  etc.,  contains  extensive  information,  the  ability  to  control  what  is 
displayed  at  any  point  of  time  will  assist  the  ABE  in  quickly  perceiving  the 
relevant  information.  Therefore,  CETOOLS  incorporates  the  ability  for  the  ABE 
to  tailor  the  display  of  graphic  information  for  his  particular  requirements  at  any 
time.  The  Display  option  from  the  menu  bar  is  used  to  control  the  combination 
of  graphics  that  are  currently  displayed  on  the  screen  and  available  on  hard 
copy  outputs.  The  currently  selected  options  will  have  a  checkmark  before  the 
command.  Figure  7-12  illustrates  the  simultaneous  display  of  both  map  and 
terrain  information  while  Figure  7-15  illustrates  the  display  of  map,  terrain,  and 
obstacle  information.  The  pull-down  menu  that  contains  the  commands 
associated  with  Report  is  illustrated  in  Figure  7-22  which  contains  the  following 
commands: 

•  FFOR  —  allows  the  user  to  display  graphical  FFOR 
information. 

•  Map  —  allows  the  user  to  display  graphical  map  information. 

•  Obstacles  —  allows  the  user  to  display  graphical  obstacle 
information. 

•  OPFOR  —  allows  the  user  to  display  graphical  OPFOR 
information. 

•  Terrain  —  allows  the  user  to  display  graphical  terrain 
information. 


7.3.9  User  Aids 

The  User  Aids  option  from  the  menu  bar  provides  a  variety  of  aids  to 
assist  the  ABE  in  his  use  of  CETOOLS.  The  pull-down  menu  that  contains  the 
commands  associated  with  User  Aids  is  illustrated  in  Figure  7-23.  It  contains 
the  following  commands: 
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Help  —  allows  the  user  to  obtain  information  on  how  to  use 
CETOOLS. 

Map  —  allows  the  user  to  modify  various  map  information  such 
as  scale. 

Measurement  Units  —  allows  the  user  to  specify  whether 
English  or  Metric  units  are  to  be  utilized. 

Time  —  allows  the  user  to  indicate  the  format  for  the  display  of 
time  information  as  local  time,  objective  time,  or  Zulu  time. 

Utilities  —  allows  the  user  to  access  and  modify  the  data 
bases  that  indicate  what  information  is  to  be  displayed  for  the 
various  screens  and  input  templates. 


7.3.10  Conclusions 

This  example  illustrates  the  capability  of  CETOOLS  to  be  an  effective 
decision  support  system  for  the  ABE  and  support  the  development  of  an 
effective  engineering  plan.  It  provides  the  flexibility  to  explore  myriad  mission 
scenarios  and  their  impact  on  the  plan.  In  addition,  the  use  of  CETOOLS  would 
shorten  the  amount  of  time  required  for  generating  an  effective  plan  thus 
allowing  the  commander  and  staff  more  time  for  the  evaluation  process.  This  is 
a  critical  factor  for  such  forces  as  the  82nd  Airborne  where  the  engineer  is 
subjected  to  severe  time  constraints  in  the  development,  evaluation,  and 
approval  of  his  plan.  Since  CETOOLS  will  be  used  a  very  dynamic,  real-world 
environment  where  the  parameters  are  continuously  changing,  the  ABE  can 
more  readily  react  to  these  changes.  CETOOLS  will  provide  an  analytic 
framework  for  the  ABE  regardless  of  his  experience  level.  A  systematic 
approach  provided  by  a  system  like  CETOOLS  will  ensure  that  all  facets  of  the 
operational  environment  are  considered. 
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8.  PHASE  II  DEVELOPMENT 


8.1  PHASE  I  FEASIBILITY  ASSESSMENT 

The  Phase  I  assessment  has  been  completed,  and  the  objectives 
stated  in  the  original  proposal  have  been  met.  The  CETOOLS  concept  is 
assessed  as  feasible.  The  detailed  investigation  and  analyses  surrounding  this 
innovative  concept  have  produced  the  following  conclusions: 


•  Accurate  judgements  concerning  the  feasibility  of  combat 
engineer  plans  is  critical  to  the  success  of  any  tactical  plan  for 
Army  combat  missions. 

•  Engineer  planning,  as  performed  currently,  is  a  complex 
process  that  may  be  prone  to  developing  plans  that  are  less 
than  optimal,  particularly  within  the  severe  time  constraints 
under  which  many  plans  must  be  developed. 

•  Current  technologies  can  be  combined  to  produce  an 
automated  decision  support  system  to  be  used  by  combat 
engineers  for  planning  combat  engineering  operations. 

•  User  profiling,  intelligent  dialogue  systems,  graphical 
representations,  and  an  explanation  facility  will  enhance  the 
usability  of  the  CETOOLS  system. 

The  primary  risk  areas  associated  with  the  development  of  the  CETOOLS 
system  are  the  system  performance  requirements  that  must  be  met  if  the  system 
is  to  offer  utility  in  an  operational  setting.  As  a  result,  careful  selection  of  the 
hardware  and  software  environment  and  the  efficacy  cf  the  software 
development  effort  throughout  the  Phase  II  effort  will  address  this  area.  System 
and  subsystem  performance  will  be  evaluated  as  each  software  module  is 
developed  and  tested  (i.e.,  planning  algorithms,  accessing  data  and  knowledge 
bases,  and  the  ability  of  the  targeted  computer  system  to  support  the  user- 
interface  and  knowledge  based  processing.) 
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Based  on  the  above  findings,  the  concept  is  judged  feasible  with  a 
low  level  of  risk.  The  Phase  II  effort  will  focus  on  the  development  of  an 
CETOOLS  version  to  assist  combat  engineer  planning  as  defined  during  the 
first  task  in  conjunction  with  the  panel  of  U.S.  Army  combat  engineers  from  the 
307th  Battalion,  82nd  Airborne  Division. 

8.2  GOALS. OF_PH ASE  II  RESEARCH. EFFORT 

The  primary  goal  of  the  Phase  II  research  effort  is  to  develop  a 
prototype  version  of  CETOOLS.  The  primary  emphasis  of  the  Phase  II  effort  is 
on  the  system  design  and  prototype  implementation.  The  prototype 
development  process  will  culminate  with  an  actual  tool  to  assist  in  combat 
engineer  planning  activities. 

8.3  PHASE  II  OBJECTIVES 

The  primary  objective  of  the  Phase  II  research  effort  is  development 
and  demonstration  of  the  prototype  CETOOLS  system.  The  effort  will  involve 
knowledge  acquisition  and  data  and  knowledge  base  development;  hardware 
and  software  configuration  and  installation;  detailed  system  design;  system 
development;  system  evaluation,  and  system  documentation.  Specific  technical 
objectives  for  each  of  these  areas  is  presented  below. 


Task  1 :  Knowledge  Acquisition 


Interview  CEs  from  the  307th  Battalion  —  Analytics  will 
interview  ABEs  as  well  as  other  members  from  the  307th 
Battalion.  Each  CE  will  be  interviewed  separately.  Interviews 
will  concern  the  identification  of  ABE'S  "rules  of  thumb",  short¬ 
cuts,  heuristics,  evaluation  techniques,  etc.  used  during  their 
planning  activities. 

Compile  baseline  information  —  The  development  team 
wiil  analyze,  combine,  and  synthesize  the  information  collected 
from  the  CE  interviews  into  a  cohesive  form. 
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•  Review  with  CEs  —  After  the  baseline  information  is 
compiled,  Analytics  will  then  review  it  with  the  entire  panel  of 
ABEs. 

•  Refine  CE  knowledge  —  The  information  generated  from 
the  CE  analysis  will  be  refined  based  upon  the  comments 
elicited  from  the  panel  of  experts. 

Task  2:  Hardware  and  Software  Acquisition  _ 


•  Install  equipment  and  software  — -  All  necessary  computer 
hardware  and  software  will  be  purchased,  configured,  and 
installed  at  Analytics's  offices. 

Task  3:  Detailed  System  Design 


Design  and  prototype  algorithms  —  The  algorithms  for 
planning  combat  operations,  management  of  assets  and 
resources,  evaluation  of  plans,  and  prioritization  of  engineer 
operations  will  be  designed  and  prototyped  with  simulated 
operational  data 

Design  databases  —  The  databases  (i.e.,  engineer  assets 
and  personnel,  standard  OPFOR  templates,  map  data)  will  be 
designed  based  on  information  obtained  during  Task  1. 

Design  knowledge  bases  —  The  CE  "expert"  knowledge 
for  planning  activities  will  be  designed  based  on  information 
obtained  during  task  1 . 

Design  and  prototype  user  interface  —  The  user 
interface  will  be  designed  and  prototyped.  Particular  attention 
will  be  devoted  to  the  interface  dialog  for  entering  and  viewing 
graphical  information  such  as  terrain  data. 

Design  and  prototype  intelligent  dialogue  mechanism 
—  The  intelligent  dialogue  mechanism  will  be  designed  and 
prototyped. 

Design  and  prototype  user  profiling  mechanism  —  The 

mechanism  for  the  user  profile  will  be  designed  and 
prototyped. 
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*  Finalize  the  design  —  The  design  of  all  of  the  components 
of  the  CETOOLS  system  will  be  finalized  and  analyzed  to 
determine  how  they  will  be  integrated. 

Task  4:  System  Development 


•  Implement  CETOOLS  con4  jI  mechanisms  —  The  high- 
level  system  shell  will  be  implemented  on  the  target  computer 
system. 

•  Implement  algorithms  —  The  algorithms  designed  and 
prototyped  in  Task  3  will  be  implemented  in  the  delivery 
environment. 

•  Implement  databases  —  The  databases  which  were 
designed  during  Task  3  will  be  implemented  and  populated. 

•  Implement  knowledge  base  —  The  knowledge  bases 
which  were  designed  during  Task  3  will  be  implemented  and 
populated. 

•  Implement  user  interface  —  The  user  interface  prototyped 
and  validated  during  Task  3  will  be  implemented  in  the  delivery 
environment. 

•  Implement  intelligent  dialogue  mechanism  —  The 
intelligent  dialogue  mechanism  prototyped  during  Task  3  will 
be  implemented  in  the  delivery  environment. 

•  Implement  user  profiling  mechanism  —  The  user 
profiling  mechanism  prototyped  during  Task  3  will  be 
implemented  in  the  delivery  environment. 

Task  5:  System  Evaluation 


Refine  algorithms  —  The  algorithms  prototyped  in  Task  3 
will  be  refined  using  data  obtained  during  Task  1. 

Refine  knowledge  bases  —  The  knowledge  bases  for  CE 
expertise  will  be  refined  using  data  obtained  during  Task  1. 
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•  Refine  user  interface  —  Opinions  on  the  user  interface 

*  prototype  wiii  be  solicited  from  the  307th  Battalion  and  U.S. 

Army  personnel  and  their  suggestions  incorporated  into  the 
final  design. 

•  Refine  intelligent  dialogue  system  —  Opinions  on  the 
intelligent  dialogue  system  prototype  will  be  solicited  from  the 
307th  Battalion  and  U.S.  Army  personnel  and  their  suggestions 
incorporated  into  the  final  design. 

•  Refine  user  profiling  system  —  During  the  review  of  the 
user  interface  and  intelligent  dialogue  system,  the  user 
profiling  system  will  be  analyzed  and  refined  as  necessary. 

Task  6:  System  Documentation _ 


•  User's  Guide  —  A  user's  guide  will  be  developed  for  use 
with  the  phase  II  version  of  CETOOLS. 

*  Phase  II  Report  —  A  report  of  progress  and  a  discussion  of 
future  development  will  be  written. 

8.4  SUMMARY 

A  set  of  system  design  criteria  were  established  following  the  Phase  I 
interviews  with  the  307th  Battalion,  82nd  Airborne  Division,  and  a  survey  of  the 
current  technologies  available.  The  following  primary  system  components 
comprise  the  CETOOLS  concept: 

1.  The  decision  support  module; 

2.  The  system  manager; 

3  The  knowledge/data  bases; 

4.  The  graphics  manager;  and 

5.  The  user  interface. 

The  results  of  the  Phase  I  research  effort  indicate  the  technical 
feasibility  of  the  CETOOLS  system.  The  obvious  utility  of  an  intelligent  tool  to 
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assist  in  the  Combat  Engineer  function  warrants  the  development  of  a  prototype 
CETOOLS  system  during  a  Phase  II  effort. 


The  CETOOLS  system  will  be  optimized  continuously  during  the 
Phase  II  development.  The  two  primary  goals  which  will  drive  the  optimization 
are: 


1.  The  ability  of  the  CETOOLS  system  to  support  the  Combat 
Engineer  in  the  development  of  effective  and  timely 
engineering  portions  of  the  OPLAN  and 

2.  The  ability  of  the  Combat  Engineer  to  utilize  the  user-computer 
interface  of  CETOOLS  with  minimal  training. 


The  first  goal  must  be  achieved  in  order  to  provide  a  useful  answer  to  the  user. 
The  second  goal  is  also  important  in  order  to  obtain  user  acceptability  of  the 
CETOOLS  system.  In  summary,  the  CETOOLS  system  provides  for  enhanced 
combat  engineer  planning  capabilities  to  meet  the  goals  of  future  U.S.  Army 
missions. 


The  advantages  of  the  decision  support  approach  incorporated  into 
CETOOLS  include  the  following: 


Ability  to  incrementally  improve  the  system.  Since  the 
Combat  Engineer's  knowledge  is  represented  in  knowledge 
bases  that  are  separate  from  the  techniques  that  are  used  to 
develop  a  plan,  the  capability  of  CETOOLS  can  be 
incrementally  extended  by  modification  of  the  knowledge 
bases  as  new  situations  occur  and  parameters  change  over 
time. 

Ability  for  the  Combat  Engineer  to  evaluate  a  plan 
and  analyze  how  to  best  utilize  available  resources. 

CETOOLS  will  incorporate  provisions  for  the  Combat  Engineer 
to  evaluate  a  plan  based  not  only  for  effectiveness  but  also  to 
evaluate  the  impact  on  available  resource  and  time  constraints. 
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Ability  for  CETOOLS  to  complement  the  Combat 
Engineer's  skills.  CETOOLS  will  provide  useful  capabilities 
to  assist  the  Combat  Engineer  as  much  as  feasible  but  still 
permit  the  human  to  make  the  final  judgement.  The 
interweaving  of  the  Combat  Engineers  skills  and  the 
CETOOLS  system  capabilities  provides  a  more  optimal 
solution  than  utilizing  either  one  separately. 
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APPENDIX  A: 

COUNTERMOBILITY  AS  A  FORCE  MULTIPLIER 


A:  COUNTERMOBILITY  AS  A  FORCE  MULTIPLIER  -  HISTORICAL 

PERSPECTIVE 


A.1.  BACKGROUND 

Countermobility,  the  effective  use  of  natural  and  man-made  obstacles 
to  halt  or  redirect  a  threat  force  advance,  has  become  an  ever  more  important 
factor  on  the  modern  battlefield.  A  foot  soldier  can  traverse  almost  any  terrain, 
but  tanks,  APCs  and  trucks  that  comprise  modern  armies  are  limited  to 
restrictive  avenues  of  approach.  Countermobility  is  a  force  multiplier  in  that  as 
the  enemy  is  stalled  by  obstacles  or  a  series  of  obstacles,  Friendly  Forces  (FF) 
may  engage  the  enemy  with  near  impunity  from  defensive  positions 
incorporated  into  the  obstacle  plan.  For  example,  the  current  numerical 
superiority  of  the  Warsaw  Pact  forces  in  armored  fighting  vehicles,  coupled  with 
their  known  doctrine  of  Blitzkrieg-like  attacks,  requires  that  friendly  forces  plan 
and  provide  for  the  use  of  multiple  obstacles  in  depth.  Also,  light  forces  such  as 
airborne  infantry  units  require  the  effective  use  of  obstacles  in  order  to  counter 
the  potential  superiority  of  Opposing  Forces  (OPFOR).  If  properly  planned  and 
implemented,  countermobility  can  provide  the  decisive  edge  needed  to  ensure 
a  successful  operation. 

The  use  of  obstacles  can  be  found  throughout  the  annals  of  military 
conflict.  In  fact,  military  history  has  shown  that  the  judicious  use  of  obstacles  by 
armed  forces  can  offset  the  superiority  of  opposing  forces  (i.e.,  numerical 
superiority  and  firepower  superiority  of  the  assets  comprising  opposing  forces.) 
However,  the  success  found  with  the  use  of  obstacles  is  shown  to  be  based  on 
a  well  conceived  countermobility  plan  that  follows  several  principles.  A 
description  of  such  countermobility  principles,  illustrated  with  historical 
examples  of  armed  conflicts  in  which  such  principles  were  either  followed  or 
ignored,  is  presented  below.  The  consequences  from  adhering  to  these 
principles  or  ignoring  them  provide  evidence  to  their  validity.  In  order  to 
understand  the  importance  of  these  countermooility  principles  on  impacting  the 
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success  of  future  conflicts,  it  is  first  necessary  to  describe  today's  battlefield 
environment. 


A.2  TODAY'S  BATTLEFIELD  ENVIRONMENT 

Several  key  points  concerning  OPFOR  doctrine  and  tactics  (i.e. , 
Warsaw  Pact)  are  important  to  understand  in  order  to  see  the  utility  of 
countermobility  plans. 

The  future  battlefield  will  be  intense,  fast,  and  deadly.  Enemy  forces, 
such  as  the  Warsaw  Pact,  will  attempt  to  gain  as  much  ground  as  quickly  as 
possible,  through  penetration  attacks  designed  to  put  large  armored  forces  in 
the  friendly  rear  areas  thus  compromising  friendly  and  logistics  elements. 
Loss  of  the  rear  areas  will  cause  the  forward  combat  element  to  fight  along  two 
separate  and  opposite  directions  --  trying  to  hold  the  enemy  along  its  front  while 
ridding  the  enemy  from  its  rear.  With  the  loss  of  C^,  combat  units  will  be 
virtually  blind  in  opposing  both  the  front  and  rear  threat.  With  the  combined  loss 
of  t.  e  logistics  bases  in  the  rear,  the  intensity  of  combat  will  soon  drain  the 
supplies  on  the  front  lines.  Threat  indirect  fire  and  NBC  capabilities  will  be 
directed  against  those  same  command,  control  and  logistics  elements  further 
degrading  their  capability  to  support  the  combat  units.  As  a  result,  friendly 
forces  must  work  to  slow  and  divert  as  much  as  possible  the  threat  advance. 
With  proper  planning  and  execution,  a  defending  army  can  halt  an  enemy  in  its 
tracks  --  exposing  the  enemy  force  to  friendly  anti-ta.ik  and  artillery  fires.  To 
ensure  this  possibility,  obstacles  are  employed  such  that  the  enemy  is 
chcnnelized  into  "killing  zones"  where  the  diminutive  size  of  the  area  and 
frie  idly  weapon  placements  combine  to  provide  an  imposed  target  rich 
en\  ronment. 

In  response  to  OPFOR  doctrine  and  tactics,  US  planners  have 
developed  an  Airland  Battle  doctrine  whereby  it  is  envisioned  that  friendly 
forces  will  be  facing  either  1)  numerically  superior  armored  and  mechanized 
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forces  attacking  along  a  broad  front  or  2)  insurgent  forces  conducting  hit  and 
run  operations  only  when  they  can  achieve  local  superiority.  AirLand  Battle 
doctrine  calls  for  a  forward  defense  and  a  slow  withdrawal  until  reinforcements 
can  arrive  on  the  scene  to  counterattack.  At  all  times,  local  commanders  should 
be  prepared  to  turn  upon  and  attack  the  enemy.  This  principle  extends  from  the 
strategic  planners  at  national  level  down  to  the  enlisted  squad  leader  in  the 
trenches.  Maximum  flexibility,  initiative,  and  resourcefulness  coupled  with 
intensive  training  and  superior  weapons  should  be  able  to  contain  the 
advancing  enemy  until  a  major  friendly  counterattack  can  be  launched.  Under 
this  doctrine,  obstacles  are  envisioned  as  fulfilling  three  functions: 

1 .  Enhance  the  effectiveness  of  friendly  anti-tank  fires, 

2.  Delay  the  enemy's  advance,  upset  his  timing,  disrupt  and 
channelize  his  formations,  and  delay  or  destroy  follow  on 
formations,  and 

3.  Enhance  friendly  economy  of  force  measures. 

In  addition  to  these  OPFOR  doctrine  and  tactics  that  focus  mainly  on 
high-intensity  conflicts  on  the  Western  European  front,  countermobility  is  of 
even  greater  importance  for  low  to  mid-intensity  conflicts  that  can  be  expected 
to  be  faced  by  light  forces  in  today's  army  such  as  the  US  Army  XVIII  Airborne 
Corps  (82nd  Airborne  Division).  Lightly  equipped  airborne  FF  must  be 
prepared  to  encounter  enemy  forces  all  along  their  defensive  perimeter  which 
could  encompass  a  360  degree  perimeter.  Also  OPFOR,  such  as  insurgent 
forces  in  low-intensity  conflicts,  can  be  expected  to  have  a  better  knowledge  of 
the  local  terrain  than  will  friendly  forces.  In  these  low-intensity  conflicts  the 
obstacle  plan  takes  on  even  greater  importance  due  to  the  relative  freedom  of 
movement  of  such  light  and  guerilla  forces.  As  a  result,  countermobility  tactics 
will  play  an  important  role  in  determining  the  success  and  survivability  of  lightly 
equipped  FF. 
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A.3  PRINCIPLES  OF  COUNTERMOBILITY 

When  preparing  and  considering  the  operational  and  logistical  plans- 
for  a  tactical  operation  and  deployment,  the  tactical  force  commander  must 
consider  the  METT-T  (Mission,  Enemy,  Terrain,  Troops  and  Time  available) 
factors  inherent  to  the  situation  at  hand.  At  the  same  time  ,  the  combat  engineer 
(CE)  is  considering  these  same  METT-T  factors  when  developing 
countermobility  plans.  Also,  the  CE  is  following  several  key  principles  that  are 
considered  to  be  paramount  to  the  planning  process  and  to  its  ensured 
success.  These  principles  are  the  following: 

1.  Countermobility  plans  must  complement  and  be  integrated  with 
the  tactical  and  strategic  mission  plans, 

2.  Countermobility  strategy  must  take  into  consideration  the 
terrain  on  which  the  battle  is  to  be  fought  in  order  to  maximize 
the  use  of  limited  resources,  assets  and  time  to  implement  any 
obstacle  plan  as  well  as  to  enhance  the  effectiveness  of  such 
plans, 

3.  Countermobility  strategy  must  plan  for  obstacle  deployment  in 
depth  as  well  as  breadth  to  ensure  effectiveness,  and 

4.  Countermobility  strategy  must  take  into  consideration  the 
anticipated  enemy  assets  and  doctrine  to  be  encountered. 

These  major  countermobility  principles  are  described  in  the  following 
subsections  with  historical  examples  used  to  illustrate  the  importance  of  such 
principles. 


A.3.1  Principle  1 :  Countermobility  plans  must  complement  and  be 
integrated  with  the  tactical  and  strategic  mission  plans. 

Effective  countermobility  plans  are  ones  that  are  fully  integrated  into 
the  FF  tactical  mission  plans.  Specifically,  obstacles  serve  as  a  force  multiplier 
only  if  obstacles  are  deployed  complementary  to  emplacement  of  fire  power 
(i.e.,  anti-tank,  artillery,  etc.)  such  that  there  is  a  synergistic  effect  from  these  two 
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combined  assets.  To  ensure  such  an  effect,  obstacle  locations  must  be 
carefully  coordinated  with  the  location  of  battle  positions  and  the  use  of  direct 
and  indirect  weapons.  Except  for  mines,  obstacles  emplaced  outside  the  range 
of  friendly  weapons  are  of  little  use.  This  is  because  the  tactical  commander's 
intention  is  to  engage  the  enemy  at  the  maximum  range  of  FF  weapons  and 
force  OPFOR  to  breach  and  fight  their  way  through  a  series  of  obstacles  while 
under  intense  fire.  In  addition,  countermobility  plans  implemented  through  the 
use  of  extensive  obstacle  systems  coupled  with  effective  fields  of  fire  allow 
limited  numbers  of  friendly  forces  to  better  hold  their  own  against  numerically 
superior  enemies.  Friendly  forces  are  able  to  fight  from  protected  defensive 
positions  while  the  stalled  enemy  is  fully  vulnerable  to  friendly  anti-tank, 
artillery,  and  air  attacks. 

The  two  basic  types  of  obstacles  that  the  CE  will  use  to  complement 
the  tactical  mission  plan  are  existing  and  reinforcing  obstacles.  Existing 
obstacles  are  any  obstacle  that  was  in  place  prior  to  the  start  of  hostilities  or  that 
has  been  placed  through  the  forces  of  nature  (such  as  snow  and  ice). 
Examples  of  existing  obstacles  include  rivers,  mountains,  cliffs,  soft  farmland, 
forests,  buildings  and  villages,  and  any  other  terrain  features  that  prevent  or 
impede  enemy  movement  during  battle.  Reinforcing  obstacles  include  such 
features  as  tank  ditches,  abatis  (a  defensive  obstacle  formed  by  felled  trees  with 
sharpened  branches  facing  the  enemy),  blown  bridges,  mine  fields,  road 
craters,  and  even  rubble  in  and  around  populated  cities  can  be  considered 
obstacles  to  an  enemy's  advance.  Thus  a  reinforcing  obstacle  is  placed  on  the 
battlefield  by  utilizing  combat  engineering  assets  and  is  designed  to  strengthen 
the  existing  natural  terrain  features.  An  obstacle  is  not  only  something  placed  in 
the  enemy's  path  such  as  the  tank  ditch,  it  can  also  be  something  denied  to  the 
enemy  such  as  a  blown  bridge  over  a  major  river  or  a  geographic  feature  that 
cannot  be  crossed. 
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The  effective  use  of  obstacles  is  illustrated  by  the  Israelis  during  the 
1973  Yom  Kippur  Syrian  invasion  summarized  below  (Allen,  1982;  Asher  & 
Hammel,  1987). 


The  Israelis  made  perfect  use  of  the  rugged  terrain  of 
the  Golan  Heights  in  their  defense  during  the 
October  1973  Yom  Kippur  Syrian  Invasion.  A  system 
of  bunkers  was  positioned  on  all  of  the  major  rises 
along  the  1967  Cease  Fire  Line  in  the  Golan 
Heights.  Supporting  all  of  these  fixed  positions, 
numerous  tank  emplacements  were  constructed 
taking  full  advantage  of  the  slope  of  the  land,  high 
ground  advantage  for  anti-tank  fires,  interlocking  fires 
from  multiple  positions,  and  prepared  tank  positions 
providing  sheltered  locations  from  which  the  Israeli 
army  could  engage  the  Syrian  forces  at  ranges  from 
2  -  3  kms.  The  Israelis  were  able  to  direct  withering, 
accurate  anti-tank  fires  against  the  Syrians  from  their 
prepared  positions  and  significantly  reduce  the 
attackers  strength  until  the  overwhelming  number  of 
the  Syrian  forces  forced  the  Israelis  to  withdraw.  In 
the  end,  however,  the  stubborn  Israeli  defense  of  the 
Golan  Heights  gave  them  enough  time  to  organize 
their  counterattack  which  virtually  destroyed  the 
Syrian  army  and  moved  the  Israeli  army  to  within 
artillery  range  of  the  Damascus  airport.  In  the  end 
the  Arabs  on  the  northern  front  (Syrians,  Jordanians 
and  Iraqui)  lost  approximately  1,300  main  battle 
tanks,  867  of  those  in  the  Golan  region  alone.  The 
Israelis  lost  only  250  tanks,  of  which  150  were  later 
returned  to  battle  (at  least  once)  during  the  course  of 
the  war. 


In  contrast  to  the  Israelis'  effective  use  of  obstacles  to  complement 
tactical  mission  plans,  the  Falklands  campaign  shows  the  dire  consequences 
when  this  principle  is  not  adhere  to  as  summarized  below  (Hastings  &  Jenkins, 
1983). 


In  the  Falklands  campaign  by  the  British  Commando  and 
Paratroop  units,  this  determined,  light  force  was  able  to 
overcome  obstacle  emplacements  set-up  by  the  Argentine 
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defenders.  Granted  the  British  were  not  facing  elite  well 
trained  units,  but  by  their  own  analysis,  the  obstacles  and  mine 
fields  they  overcame  should  have  held  much  longer.  For 
example,  the  Argentines  destroyed  bridges  in  an  attempt  to 
impede  the  British.  However,  the  Argentines  did  not  attempt  to 
defend  the  far  side  of  the  river  crossings.  The  British  crossed 
the  rivers  with  impunity.  Similarly,  the  Argentines'  use  of  mine 
fields  was  ill-advised.  The  Argentines  constructed  elaborate 
mine  fields  but  failed  to  cover  the  mine  fields  with  supporting 
firepower  once  the  British  had  entered  such  areas.  In  fact, 
during  a  lull  at  night  in  the  Battle  for  Goose  Green,  British 
troops  slept  in  depressions  on  the  ground  while  waiting  for  the 
next  phase  of  the  attack.  Only  with  the  first  light  of  day  did  the 
British  troops  realize  that  they  were  sleeping  in  the 
depressions  left  by  exploded  land  mines  from  cattle  that  were 
grazing  in  the  area. 


A.3.2  Principle  2:  Countermobility  planning  must  take  into  consideration  the 

terrain  on  which  the  battle  is  to  be  fought. 

Countermobility  strategy  must  take  into  consideration  the  terrair  on 
which  the  battle  is  to  be  fought  in  order  to  enhance  the  effectiveness  of  such 
plans  as  well  as  to  maximize  the  use  of  limited  resources,  assets,  and  time  to 
implement  any  obstacle  plan.  Maximum  use  must  be  made  of  the  terrain  as  it 
exists.  Rivers,  steep  slopes,  narrow  valleys  and  mountain  passes,  and  towns 
and  villages  must  be  incorporated  into  the  countermobility  plan.  The  enemy's 
probable  avenue  of  approach  must  be  identified  and  analyzed  to  find  the  best 
areas  to  interdict  his  forces.  Where  possible,  natural  choke  points  should  be 
used  to  form  killing  zones  to  reduce  enemy  forces.  Terrain  analysis  by  the  CE 
should  not  only  consider  terrain's  detrimental  effects  on  the  enemy,  but  also 
identify  key  terrain  that  will  aid  in  the  friendly  defense,  such  as  rises  and 
defilade  positions  that  will  allow  friendly  forces  to  observe  and  fire  on  the  enemy 
while  providing  cover  and  concealment  to  the  friendly  unit.  Only  after  the  terrain 
has  been  analyzed  should  attention  be  turned  to  the  possibility  of  enhancing 
the  effectiveness  of  the  chosen  battlefield.  Historically,  this  idea  has  been 
neglected  at  critical  times  during  campaigns  as  described  below  (MacDonald, 
1983). 
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The  Ardennes  region  of  northern  France  and 
Belgium  is  an  ideal  illustration  of  a  region  whose  role 
in  strategic  events  has  been  overlooked  continually 
in  modern  warfare.  The  rough,  hilly,  wooded  country 
was  believed  too  rough  for  rapid  advance  by 
mechanized  forces.  But  the  German  armies  used 
this  route  in  their  lead  attacks  in  both  1914  and  1940. 
The  French  and  British  in  both  cases  failed  to  notice 
that  the  road  network  of  the  region  directed  traffic  into 
France  was  pointed  straight  for  Paris.  The  French 
and  British  did  not  attempt  to  build  obstacles  to 
circumvent  the  use  of  these  roads.  In  fact,  second 
and  third  line  troops  were  placed  in  this  front  line 
area  in  the  belief  that  the  Germans  could  not  possibly 
launch  an  attack  through  this  region.  In  1914,  the 
Germans  were  stopped,  but  not  so  in  their  advance 
of  1940. 


However,  the  Germans  failed  to  learn  from  their  past  successes  in  this 
region  as  described  below. 


In  December,  1944  the  Germans  again  attacked 
through  the  Ardennes,  but  this  time  they  neglected  to 
plan  their  advance  to  capitalize  on  existing  road 
networks.  The  German  armored  columns  tried  to 
maneuver  against  the  road  network.  The  German 
advance  was  slowed  down  enough  to  give  the  Allied 
armies  in  other  areas  enough  time  to  disengage, 
reorient  their  axes,  and  counterattack  before  the 
Germans  reached  the  open  plains  of  northern 
France. 


Terrain  analysis,  with  respect  to  countermobility  planning,  involves 
understanding  the  implications  of  terrain  features.  That  is,  how  can  one  best 
use  terrain  features  to  one's  advantage  when  developing  and  implementing  an 
obstacle  plan.  To  follow  are  descriptions  that  highlight  some  of  the  major 
natural  terrain  features  which  are  important  considerations  for  countermobility 
planning. 
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Drainage  features  are  one  of  the  most  obvious  natural  terrain 
obstacles.  Deep,  swift  rivers  and  streams  will  stop  most  armored  forces.  These 
features  can  be  rendered  even  more  effective  by  stormy  weather  or  controlled 
flooding.  Most  armored  vehicles  can  ford  small  streams  and  river  while  very 
small  streams  are  no  obstacle  at  all  as  the  AFVs  can  self-bridge  them.  Major 
drainage  features  will  usually  require  some  sort  of  additional  engineer  support 
to  exploit.  As  an  enemy  tries  to  send  numerous  vehicles  across  a  fordable 
stream,  bottom  conditions  at  the  ford  site  will  increase  the  tendency  for  vehicles 
to  become  bogged  down  in  the  churned  up  bottom.  Some  AFVs  have 
snorkeling  or  swimming  capability  but  this  is  also  dependent  upon  the  width, 
depth,  and  speed  of  the  river.  Rivers  with  steep  banks  also  increase  the 
difficulty  that  a  force  will  have  in  crossing.  Lakes  and  ponds,  by  their  nature, 
tend  to  make  excellent  obstacles.  Because  it  is  usually  easier  to  go  around 
rather  than  across  one  of  these  bodies,  large  forces  will  tend  to  do  just  that. 
Thus  drainage  features  tend  to  slow  the  enemy  on  the  far  bank  as  they  prepare 
for  the  crossing  operation.  Once  the  crossing  or  bypass  operation  has  been 
started,  the  enemy  forces  must  be  channelized  through  the  crossing  points  or 
close  ranks  as  they  maneuver  around  the  edges  of  lakes  and  ponds.  This 
provides  target  rich  environment  for  friendly  weapons. 


The  use  of  natural  terrain  features  such  as  rivers  is  one  that  has 
impacted  the  success  of  military  operations  as  illustrated  below  (Calvocoressi  & 
Wint,  1972). 


As  the  Allied  forces  during  the  later  stages  of  WWII 
advanced  on  the  Rhein  River,  the  Germans  pulled 
back  to  the  Siegfried  Line.  As  part  of  the  German 
withdrawal  the  bridges  across  the  Rhein  were 
destroyed.  The  Allies  were  effectively  stopped  in 
their  advance  except  for  one  remaining  bridge  that 
was  still  intact  --  Remagen  Bridge.  The  Remagen 
Bridge  was  being  held  intact  by  a  reinforced  infantry 
company  to  allow  for  the  escape  of  German  forces  on 
the  west  bank  of  the  river.  The  engineer  detachment 
commander  was  ordered  to  demolish  the  bridge  only 
on  the  written  order  of  the  infantry  commander,  but 
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the  infantry  commander  did  not  have  dear  orders 
concerning  the  fate  of  the  bridge.  When  large 
numbers  of  troops  started  streaming  east  across  the 
bridge,  the  German  LXV1I  Corps  commander  sent 
MAJ  Schelier  to  assume  command  of  the  situation 
with  orders  to  hold  the  bridge  until  the  last  possible 
moment.  When  American  tanks  and  infantry 
appeared  at  the  west  end  of  the  bridge,  the  Germans 
fired  a  crater  in  an  attempt  to  slow  the  American 
advance.  Next,  when  they  tried  to  blow  the  bridge 
electrically,  they  found  that  the  circuit  had  been 
damaged.  The  Germans  then  tried  to  ignite  the 
explosives  manually  but  this  failed  to  destroy  the 
bridge.  This  was  their  last  chance  as  the  bridge  fell 
into  American  hands  with  the  next  attack.  Eight 
thousand  US  soldiers,  including  one  tank  battalion 
were  able  to  cross  the  bridge  in  the  next  24  hours  to 
continue  the  Allied  advance  into  Germany.  Such 
actions  by  the  Allied  forces  substantially  impaired  the 
German  effort  to  re-group  and  counter  the  Allied 
advance. 


The  slope  of  the  land  can  inhibit  enemy  movement.  Vehicles 
cannot  easily  traverse  steep  ground.  Cliffs,  wadis,  and  embankments  will  tend 
to  slow  an  armored  vehicle  or  truck,  if  not  outright  stopping  it.  This  will  require 
the  use  of  engineer  support  to  cross  the  obstacle  or  require  the  diversion  of  the 
force  around  the  terrain.  Hills  and  mountains  tend  to  be  bypassed  by  armor  in  a 
rapid  advance.  Yet  this  same  high  ground  provides  perfect  vantage  points  for 
defensive  observers  and  weapon  systems.  Reverse  slope  positioning  along  the 
crest  of  the  hill  or  ridge  allows  the  defender  the  protection  of  the  very  ridge  upon 
which  he  sits.  Prepared  positions  scraped  from  the  hillside  can  provide  this 
same  advantage  along  the  crest  or  forward  slope  of  the  terrain.  An  example  of 
the  use  of  terrain  with  respect  to  the  slope  of  the  land  is  provided  below 
(Greenwald,  1988). 


The  increasingly  successful  Mujahadin  in 
Afghanistan  have  shown  that  proper  use  of  terrain 
can  help  turn  the  tide  away  from  heavily  armored 
forces  in  favor  of  lightly  armed  forces.  The  recent 
Soviet  action  to  resupply  the  garrison  town  of  Khost 
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in  the  mountains  of  eastern  Afghanistan 
demonstrates  the  difficulty  of  directing  armored  units 
through  well  defended  mountain  passes.  Although 
the  Soviet  push  was  successful,  it  was  a  costly  and 
slow  advance.  Reports  put  the  guerilla  casualties  at 
only  50  dead  and  several  dozen  wounded  while 
medical  authorities  in  Kabul  report  "hundreds"  of 
dead  Soviet  and  government  Afghan  soldiers  and  a 
"record  number"  of  casualties  from  the  fighting 
around  Khost. 


In  contrast,  the  Argentine  Defense  of  Port  Stanley  during  the 
Falklands  campaign  shows  that  poor  implementation  of  a  countermobility  plan 
is  doomed  to  failure  regardless  of  the  advantages  offered  by  terrain  features  as 
described  below  (Hastings  &  Jenkins,  1983). 


The  Argentine  defense  of  Port  Stanley  was  based  on 
two  mountain  ridges  around  the  city.  But  despite 
excellent  stockpiles  of  weapons  and  numerically 
superior  troops,  the  Argentines  could  not  hold  the 
ridges.  By  British  admissions,  the  defense  network 
built  into  the  ridges  should  have  held  longer  than 
what  actually  occurred.  However,  the  Argentines 
made  no  provisions  to  transport  large  stockpiles  of 
food,  clothing  and  ammunition  from  Port  Stanley  to 
these  mountain  ridges.  As  a  result,  the  British  were 
able  to  defeat  the  Argentines  with  impunity. 


Vegetation  can  be  an  important  impedence  to  cross  country  travel 
by  armored  forces.  Dense  forests  cannot  be  navigated  by  armored  forces.  The 
vehicles  usually  are  simply  too  large  to  fit  between  the  trees.  If  tree  spacing 
does  permit  the  vehicles  to  pass  through,  progress  is  usually  slow  as  the 
vehicles  must  constantly  alter  course  to  avoid  another  tree  that  appears  in  the 
way  of  advance.  For  example,  this  type  of  maneuvering  can  wear  on  the 
psychological  condition  of  tank  crews.  Scrub  brush  and  grasses  on  relatively 
open  areas  present  their  own  difficult  conditions.  Such  vegetation  may  hide 
ditches  and  gullies  that  present  major  obstacles  to  armor.  If  the  unit  is  not 
aware  of  these  gullies,  the  gullies  could  immobilize  the  first  vehicles  to 
encounter  them  and  thus  slow  the  entire  force.  This  is  especially  important 
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when  the  gullies  are  too  small  to  be  shown  on  tactical  combat  maps.  Friendly 
defenses  can  also  take  advantage  of  these  same  depressions  as  ambush  sites. 
Once  again  when  the  enemy  force  slows  or  stops  to  bring  engineers  forward  to 
breach  these  areas,  friendly  fire  can  be  brought  to  bear  on  the  enemy. 


The  effects  of  vegetation  on  defending  and  attacking  forces  can  best 
be  viewed  from  the  experiences  of  the  US  Army  in  South  Viet  Nam  as 
summarized  below  (Calvocoressi  &  Wint,  1972). 


The  jungle  greatly  curtailed  the  forces  that  the  US 
could  bring  to  bear  on  the  Viet  Cong.  The  light 
infantry  forces  were  able  to  maneuver  in  the  jungle 
with  ease,  but  the  guerillas  were  also  able  to  take 
advantage  of  the  jungle  (i.e.,  use  of  concealed  tunnel 
systems).  What  few  mechanized  units  the  US  sent 
were  limited  to  patroling  the  road  network  in  the 
south. 

Simliar  effects  of  vegetation  on  military  tactics  were 
experienced  during  the  Burma  Campaign  of  WW  II. 
As  a  result,  traditional  military  tactics  were  found  to 
be  of  little  use  under  these  circumstances. 


Besides  natural  terrain  features,  cultural  features  have  long  been 
used  as  elements  of  defense.  Typically  cities  are  bypassed  by  armored  forces 
in  an  effort  to  avoid  such  man-made  obstacles.  Cities,  with  their  tall  buildings 
and  narrow  streets,  are  virtual  deathtraps  to  armor.  They  provide  innumerable 
vantage  points  for  observers  and  anti-tank  weapons.  Stone  walls,  hedgerows, 
dikes,  and  canals  in  urban  and  suburban  areas  also  tend  to  slow  and 
channelize  the  enemy  while  providing  excellent  cover  and  concealment  to 
friendly  forces.  An  example  of  the  use  of  cultural  features  for  defense  is 
presented  below  (Calvocoressi  &  Wint,  1972). 

During  WWII  the  Germans  decided  it  was  more 
advantageous  to  starve  and  bombard  the  inhabitants 
of  the  city  of  Leningrad  than  to  direct  an  assault 


A- 12 


against  the  city  and  face  heavy  losses  because  of  the 
vantage  points  offered  by  city  buildings  and 
architecture  against  their  forces.  However,  the 
Russians  were  able  to  withstand  the  prolonged 
German  bombardment  and  encirclement  of 
Leningrad. 


A.3.3  Principle  3:  Countermobility  strategy  must  plan  for  obstacle 

deployment  in  depth  as  well  as  breadth  to  ensure  effectiveness. 

Each  natural,  as  well  as  man-made  obstacles,  can  individually  stop 
and  divert  the  enemy,  but  when  combined  their  effectiveness  is  even  more 
telling.  Forested  slopes  have  the  potential  to  block  even  the  most  powerful  tank. 
But,  fallen  trees  on  a  slope  or  hill  will  have  a  synergistic  effect  on  preventing 
tank  maneuverability.  The  tank  simply  cannnot  gain  the  momentum  required  to 
overcome  both  obstacles.  Mixing  of  these  features  in  depth  is  especially 
valuable  when  trying  to  guide  an  enemy  into  a  killing  zone  because  a  force  will 
usually  try  to  bypass  obstacles  in  depth  rather  than  breach  them. 


The  1 973  Yom  Kippur  war  illustates  the  effective  use  of  obstacles  in 
depth  (Allen,  1982;  Asher  &  Hammel,  1987). 


On  the  Golan  Heights  tank  trenches,  mine  fields, 
concertina,  pill  boxes  and  tank  ramps  were  placed  in 
depth  by  the  Israeli.  As  recounted  earlier  in  this 
section,  the  Syrians  tanks  were  effectively 
neutralized  by  the  Israeli  countermobility  plan  (i.e., 
867  Syrian  tanks  were  put  out  of  operation). 


By  contrast,  the  French  defenses  prior  to  the  outbreak  of  WWII 
violated  the  principle  of  deploying  obstacles  in  depth  as  presented  below 
(Calvocoressi  &  Wint,  1972). 


The  French  built  a  sophistacted  line  of  obstacles, 
fortified  bunkers  and  gun  emplacements  along  the 
French/German  border  known  as  the  French  Maginot 
Line.  At  the  outset  of  WWII,  the  Germans  simply 
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bypassed  the  defenses  of  the  Maginot  Line  and 
attacked  through  the  relatively  undefended  Ardennes 
region. 


A  more  recent  example  involves  the  Israeli  defense  along  the  Suez 
Canal  prior  to  outbreak  of  the  1973  Yom  Kippur  War  as  described  below 
(O'Ballance,  1978). 


The  Israeli  defensive  positions  were  too  far  forward 
along  the  Suez  Canal  with  little,  if  any,  prepared 
defensive  tank  positions.  Also,  this  Israeli  Bar  Lev 
Line  contained  no  defensive  positions  in  depth  in 
case  the  Egyptians  were  able  to  breakthrough  the 
defensive  positions  along  the  Suez  Canal.  Because 
of  this  poor  countermobility  strategy,  the  Egyptians 
were  able  to  cross  the  Suez  Canal  before  the  Israeli 
forces  were  able  to  recover  from  the  Egyptian 
preparatory  artillery  barrage.  Once  the  Egyptians 
had  established  an  adequate  bridgehead  for  their 
forces,  they  were  able  to  bypass  the  other  Isreali 
positions  along  the  Suez  Canal.  If  it  were  not  for  the 
reluctance  of  the  Egyptians  to  take  the  initiative  and 
breakout  from  their  bridgehead,  the  Israeli  forces 
could  not  have  been  able  to  mount  a  successful 
counterattack. 


A.3.4  Principle:  4:  Countermobility  strategy  must  take  into  consideration  the 

anticipated  enemy  assets  and  doctrine  to  be  encountered. 

Since  countermobility  entails  the  use  of  many  different  types  of 
natural  and  man-made  obstacles,  the  selection  of  obstacles  will  be  dictated  to  a 
large  degree  by  the  anticipated  enemy  assets  and  doctrine  to  be  encountered. 
Namely,  some  obstacles  are  more  effective  than  others  in  neutralizing  specific 
enemy  assets  (i.e.,  tanks)  as  well  as  disrupting  enemy  tactics  (i.e.,  high  speed 
execution  of  offensive  operations).  The  combat  engineer  must  take  into  account 
the  effectiveness  of  obstacles  to  counter  specific  enemy  assets  and  tactics.  For 
example,  Soviet  doctrine  presupposes  strict  time  schedules  and  routes  with 
most  operations  planned  to  the  smallest  detail.  Soviet  tactical  commanders  rely 
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on  well-rehearsed  battle  drills  that  foster  a  high  degree  of  coordination  between 
combined  arms  teams.  Because  of  such  training,  it  is  anticipated  that  Soviet 
tactical  commanders  will  not  be  able  to  deal  decisively  with  unanticipated 
conditions  that  require  a  flexible  response.  As  a  result,  obstacles  which 
effectively  slow  the  tempo  of  battle  for  a  Soviet  advance  could  disrupt  not  only 
their  plans  but  also  create  potential  bottlenecks  whereby  reinforcing  and 
succeeding  units  combine  with  those  already  at  the  front  to  create  a  target 
enriched  environment  for  friendly  fire.  Thus  denying  the  enemy  full  use  of 
facilities  along  his  chosen  avenues  of  approach  could  cripple  an  otherwise 
devastating  attack. 

To  illustrate  how  the  use  of  obstacles  can  be  enhanced  by  knowledge 
of  enemy  assets  and  their  military  tactics,  a  brief  description  of  mine  warfare 
follows.  Mines  are  either  anti-personnel  or  anti-armor.  Mine  fields  are  usually 
sown  with  a  combination  of  different  mine  types  (i.e.,  anti-personnel  and  anti¬ 
armor)  with  the  ratio  dependent  upon  the  anticipated  threat  (i.e.,  number  of 
armored  vehicles  and/or  troops).  They  can  be  emplaced  by  a  variety  of  means 
to  include  hand  emplacement,  mechanical  mine  planters,  artillery,  and/or 
aircraft.  Conventional  mine  fields  are  usually  planted  before  the  battle  begins, 
and  then  as  the  battle  progresses,  the  original  mines  are  reseeded  and 
supplemented  by  scatterable  mine  fields  from  artillery  or  aircraft.  Mine  fields, 
like  tank  ditches,  are  best  used  to  slow  the  enemy  while  the  enemy  forces  are 
entering  or  traversing  a  choke  point,  thus  allowing  friendly  forces  to  bring  all 
weapons  to  bear  from  concealed  positions.  The  makeup  of  a  mine  field  with 
respect  to  type  and  number  of  mines  (density)  will  be  dictated  by  the  anticipated 
enemy  force  composition. 

During  the  Viet  Nam  conflict,  claymore  mines  (anti-personnel)  were 
effectively  used  to  counter  the  Viet  Cong  as  described  below. 

Claymore  mines  expel  their  projectiles  outward  in  a 
wide  arc  thus  killing  more  of  the  enemy  than  just  the 
one  who  triggers  it.  For  example,  claymore  mines 
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were  used  to  trigger  ambushes  such  that  portions  of 
Viet  Cong  patrols  were  allow  to  pass  before  the 
mines  were  manually  triggered  by  American  forces  to 
start  the  attack.  Claymore  mines  were  often 
detonated  manually  when  the  Viet  Cong  could  no 
longer  be  controlled  with  small  arms.  Also,  claymore 
mines  were  sown  around  the  perimeters  of  fire  bases 
to  offset  the  Viet  Cong's  ability  to  conduct  snipper 
attacks  up-close  at  night. 


However,  mines  are  not  the  panacea  that  they  may  appear  to  be. 
There  are  numerous  examples  of  mine  warfare  that  failed  to  deter  the  enemy,  or 
to  even  wound  the  enemy  because  the  forces  employing  the  use  of  mine  fields 
failed  to  take  into  account  the  enemy's  tactics  or  the  element  of  luck.  Examples 
from  the  Falklands  campaign  are  described  below  (Insight  Team  of  the  Sunday 
Times  of  London,  1982). 


During  the  Falklands  campaign  the  British  SAS 
advanced  toward  the  Argentine  troops  at  Grytviken 
on  South  Georgia  island.  The  British  were  met  by  an 
incredulous  Argentine  officer  complaining  that  they 
had  just  walked  through  a  mine  field  and  had  failed 
to  detonate  a  single  mine.  Luck  was  on  the  side  of 
the  British  that  day. 

During  the  British  advance  on  Port  Stanley  on  East 
Falkland  Island,  the  British  had  ampie  opportunities 
to  reconnoiter  their  advance  routes  with  engineers 
marking  out  the  mine  fields  and  paths  through  them. 
Although  these  missions  did  produce  some  British 
casualties,  they  were  successful  in  clearing  many  of 
the  British  avenues  of  approach. 


A.4  CONCLUSION 

As  illustrated  in  this  section,  the  success  of  any  countermobility  plan 
will  be  determine  to  a  large  extent  by  the  careful  consideration  of  METT-T 
factors  (Mission,  Enemy,  Terrain,  Troops,  and  Time  available)  inherent  to  the 
situation  at  hand. 
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APPENDIX  B: 

CETOOLS  USER-COMPUTER  INTERFACE  COMPONENTS 


B:  CETOOLS  USER-COMPUTER  INTERFACE  COMPONENTS 


This  section  describes  the  proposed  components  for  the  user- 
computer  interface  (UCI)  for  CETOOLS. 


B.1  INPUT  DEVICES 

The  UCI  input  devices  consist  of  the  following  complementary  devices 
—  a  keyboard,  a  mouse,  and  a  digitizing  tablet. 

B.i  .1  Keyboard 

The  keyboard  is  used  to  enter  alphanumeric  data  and  as  an 
alternative  to  the  use  of  the  mouse  to  move  the  text  cursor  between  input  fields 
on  dialogue  boxes.  The  keyboard  consists  of  a  standard  typewriter  keyboard, 
numeric  keypad  overlaid  with  cursor  move  keypad,  and  a  set  of  function  keys. 

The  numeric  keypad  includes  keys  for  the  numbers  zero  through  nine 
arranged  in  an  adding  machine  format;  it  aiso  has  keys  for  special  functions 
(such  as  a  minus  sign,  equal  sign,  etc.)  and  is  used  to  speed  entry  of  numeric 
information.  The  cursor  movement  keypad  contains  an  up-arrow,  down-arrow, 
right-arrow,  left-arrow,  home,  and  end  keys  and  are  used  to  control  cursor 
movement  within  a  window  as  an  alternative  to  the  use  of  the  mouse.  The  user 
controls  the  functioning  of  the  keypad  as  either  a  numeric  pad  or  cursor 
movement  pad  through  the  use  of  the  NUM  LOCK  key.  Above  the  num  lock 
key  is  a  small  red  dot  light.  If  the  light  is  lit,  then  the  keypad  is  functioning  as  a 
numeric  pad;  otherwise  it  functions  as  a  cursor  movement  pad.  The  special 
function  keys  are  used  to  select  menu  options  as  an  alternative  to  the  use  of  the 
mouse  for  experienced  users  with  certain  modules. 
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B.1.2  Mouse 

The  mouse  is  used  as  a  pointing  device  to  select  commands  from 
menus,  to  control  cursor  (pointer)  movement,  and  to  manage  file  scrolling.  In 
CETOOLS,  the  standard  pointer  is  an  arrow  (s).  Every  move  you  make  with  the 
mouse  moves  the  pointer  in  exactly  the  same  way.  The  following  terms 
describe  various  actions  associated  with  mouse  utilization: 

•  Clicking  —  positioning  the  pointer  with  the  mouse,  briefly 
pressing  and  releasing  the  mouse  button  without  moving  the 
mouse. 

•  Pressing  —  positioning  the  pointer  with  the  mouse,  holding 
down  the  mouse  button  without  moving  the  mouse. 

•  Dragging  —  positioning  the  pointer  with  the  mouse,  holding 
down  the  mouse  button,  moving  the  mouse  to  a  new  position, 
then  releasing  the  button. 

These  terms  will  be  used  in  subsequent  sections  to  describe  user  interactions 
with  CETOOLS. 


B.1.3  Digitizing  Tablet 

The  digitizing  tablet  will  be  used  for  direct  input  of  graphics 
information  from  a  hard  copy  map  or  diagram.  The  user  will  utilize  the  tablet  to 
trace  over  key  features  and  input  into  CETOOLS.  The  buttons  on  the  digitizing 
tablet  will  be  under  control  of  CETOOLS  so  that  their  function  can  be  modified 
depending  upon  application.  For  example,  when  defining  terrain,  the  buttons 
will  correspond  to  various  terrain  features  such  as  high  points,  roads,  rivers,  etc. 
When  defining  obstacles,  the  buttons  will  correspond  to  obstacle  features  such 
as  mine  fields,  road  cracters,  and  tank  ditches. 
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B.2  SCREEN  LAYOUT  AND  COMPONENTS 

This  section  describes  how  information  is  arranged  on  the  display 
and  how  the  user  interacts  with  the  particular  component.  The  screen  is 
arranged  into  four  main  areas: 


1.  The  title  bar  which  is  always  on  the  top  line  of  the  display  as 
described  in  Section  B.2.1; 

2.  The  menu  bar  which  is  always  the  second  line  of  the  display 
as  described  in  Section  B.2.2; 

3.  The  function  key  bar  which  is  always  the  last  line  on  the 
display  as  described  in  Section  B.2.3;  and 

4.  The  CETOOLS  window  which  occupies  the  remainder  of  the 
screen.  The  CETOOLS  window  is  used  to  conduct  a  dialog 
with  the  user.  It  will  either  display  information  to  the  user  or 
display  an  input  form  for  the  user  to  supply  the  information 
CETOOLS  requires.  The  contents  vary  dependant  upon  the 
current  function.  The  windows  are  described  in  Sections  B.2.4 
through  B.2.8. 


Within  the  CETOOLS  window,  a  variety  of  components  have  been  developed 
for  the  user  to  specify  particular  simulation  data  items  or  supplying  additional 
information  required  before  a  system  command  can  be  processed.  These 
components  include: 


1.  List  Selection  Box  —  a  scrollable  list  of  available  items  for 
the  user  to  select  from  as  described  in  Section  B.2.9; 

2.  List  Viewing  Box  —  a  scrollable  list  of  currently  defined 
terms  for  the  user  to  view  as  described  in  Section  B.2.1 0: 

3.  Pushbutton  —  a  distinct  area  of  the  screen  that  is  used  to 
specify  actions  as  described  in  Section  B.2.1 1 ; 

4.  Click  Boxes  —  a  box  containing  the  range  of  numeric  values 
that  can  be  modified  by  the  user  via  mouse  clicks  as  described 
in  Section  B.2.1 2; 
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5. 


Text  Entry  Boxes  —  a  rectangular  box  which  allow  the  user 
to  enter  textual  data  (numeric  or  alphanumeric)  with  the  size  of 
the  box  iodicating  the  maximum  number  of  characters 
permitted  as  described  in  Section  B.2.13; 

6.  Scroll  Bar  —  a  rectangular  box  that  is  used  to  modify  the 
current  view  of  a  window  as  described  in  Section  B.2.14;  and 

7.  Labels  —  text  descriptions  used  to  indicate  the  type  of 
information  to  be  entered  by  the  user  as  described  in  Section 
B.2.15. 

8.  Radio  Buttons  —  small  circles  that  are  used  to  indicate  that 
the  user  can  select  only  one  of  a  set  of  mutually  exclusive 
options  as  described  in  Section  B.2.16. 

9.  Check  Boxes  —  small  rectangular  boxes  that  represent 
options  that  can  be  activiated  simulaneously  and  contain  an  X 
when  activiated  as  described  in  Section  B.2.17. 


CETOOLS  uses  two  distinct  cursors  to  represent  the  focus  of  attention 
for  the  user  and  point  to  a  precise  point  on  the  screen.  The  mouse  cursor  is 
controlled  by  the  mouse  and  always  represents  the  last  mouse  screen  location. 
When  the  user  moves  the  mouse,  the  mouse  cursor  moves  proportionately.  The 
mouse  cursor  is  described  in  Section  B.2.18.  Additionally,  a  keyboard  cursor 
represents  the  location  where  any  keyboard  actions  will  occur  and  is  described 
in  Section  B.2.19. 


In  subsequent  sections  the  following  terminology  is  used  to  describe 
various  aspects  of  the  screen  components: 


Location  —  indicates  where  the  component  is  placed  on  the 
display.  In  some  cases,  the  exact  location  will  vary  depending 
upon  the  contents  of  the  screen; 

Background  Color  —  indicates  the  color  to  be  used  for  the 
screen  background  upon  which  text  and/or  graphics  will 
appear; 


B*4 


Text  Color  —  indicates  the  color  to  be  used  for  all 
alphanumerics  and  text  symbols; 

Graphics  Color  —  indicates  the  color  to  be  used  for  graphics 
symbols; 

Border  —  indicates  the  color  to  be  used  for  the  line  border 
enclosing  a  particular  eleme.it  of  the  screen; 

Characters  —  indicates  the  case  to  be  used  for  text,  e.g.,  all 
upper  case,  initial  upper  case,  etc.;  and 

User  Action  —  describes  how  the  user  will  interact  with  the 
particular  screen  component. 


B.2.1  Title  Bar 

The  title  bar  presents  information  about  the  currently  selected 
CETOOLS  function  to  the  user;  the  user  does  not  enter  any  information.  The 
title  bar  is  continuously  displayed.  The  title  bar  is  split  into  three  areas: 

1 )  Current  activity  on  left  side  of  line,  left  justified  with  initial  caps, 
if  required. 

2)  Function  name  centered  in  middle  of  line  in  uppercase  white 
letters  on  black  background. 

3)  Status  information  on  right  side  of  line  with  initial  caps,  if 
required. 


Location:  Top  line  of  screen. 

Background  Color:  White 


Text  Color: 
Graphics  Color: 
Border: 
Characters: 
User  Action: 


Black 

None 

None 

Varies  depending  upon  area. 

Information  only,  no  user  response  permitted  in  the 
title  bar  area  of  the  screen. 
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B.2.2  Menu  Bar 

It  contains  a  list  of  the  menu  titles  of  the  primary  options  that  are 
available  for  the  current  CETOOLS  function.  The  menu  bar  is  continuously 
displayed  on  the  screen.  The  last  two  menu  options  are  always  User  Aids  and 
Exit.  Each  menu  title  is  separated  from  other  menu  titles  by  one  leading  and 
two  trailing  spaces. 

Location:  Second  line  on  screen. 

Background  Color:  Blue. 

White. 

None. 

None. 

Initial  upper  case  only. 

To  select  an  option  from  the  menu  bar,  the  mouse  is 
used  to  position  the  mouse  cursor  anywhere  on  the 
desired  menu  title.  Without  moving  the  mouse,  any 
mouse  button  is  pressed  and  held  (clicking).  Once 
the  mouse  button  is  depressed,  the  selected  menu 
title  will  be  shown  in  reverse  video  (white 
background  and  blue  foreground)  and  a  box 
containing  the  available  commands  (pull-down 
menu)  will  appear  immediately  beneath  it  in  a 
separate  window.  The  pull-down  menu  will 
disappear  as  soon  as  the  mouse  button  is  released. 
In  order  to  view  all  the  puil-down  menus,  the  user 
can  drag  the  mouse  across  the  menu  bar  and  as 
each  menu  title  is  selected,  the  accompanying  pull¬ 
down  menu  will  be  displayed. 

B.2.3  Function  Kev  Bar 

The  function  key  bar  contains  a  descriptive  legend  for  each  of  the 
operational  function  keys;  the  user  does  not  enter  any  information.  The  function 
key  bar  is  continuously  displayed.  The  function  key  legend  shows  a  mnemonic 


Text  Color: 
Graphics  Color: 
Border: 

Characters.: 

User  Action: 
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for  each  function  key  as  Fn  where  n  is  the  function  key  number  followed  by  an 
equal  sign  and  a  brief  descriptor  of  the  function  such  as  F10=Exit. 


Location: 

Background  Colon 

Text  Color: 
Graphics  Color: 

Border: 

Characters: 

User  Action: 


Bottom  line  of  screen. 

White. 

Blue. 

None. 

None. 

Initial  upper  case. 

Information  only,  no  user  response  permitted  in  the 
function  key  bar  area  of  the  screen. 


B.2.4  Pull-Down  Menus 

The  pull-down  menu  is  a  separate  rectangular  window  displayed 
beneath  the  menu  bar  containing  the  list  of  commands  available  for  a  particular 
menu  title  on  the  menu  bar.  It  is  displayed  only  from  the  time  the  mouse  button 
is  held  down  and  the  mouse  arrow  is  dragged  down  through  the  menu  options 
until  the  mouse  button  is  released.  The  pull-down  menu  window  may  obscure 
the  previous  contents  of  the  screen  while  it  is  active. 


location: 


Background  Color: 
Text  Color: 
Graphics  Color: 
Beider: 

Characters: 

User  Action: 


A  separate  rectangular  window  whose  top  is 
immediately  beneath  the  menu  bar  and  upper  left 
corner  is  aligned  with  the  selected  menu  title.  The 
menu  text  is  indented  two  spaces  to  the  left  of  the 
selected  menu  title.  The  window  is  one  space  wider 
than  the  title  of  the  longest  command  title. 

Blue. 

White. 

None. 

None. 

Initial  upper  case  only. 

To  choose  one  of  the  listed  commands  in  the  pull¬ 
down  menu,  the  mouse  is  used  to  move  the  mouse 


B-7 


pointer  to  the  displayed  menu  title  on  the  menu  bar. 
While  the  mouse  button  is  held  down,  the  mouse  is 
used  to  move  the  mouse  pointer  to  the  desired 
command  (dragging).  When  the  mouse  pointer  is 
located  over  the  selected  command,  the  mouse 
button  is  released.  As  the  mouse  pointer  moves  to 
each  command  line,  the  currently  selected  command 
is  highlighted  in  reverse  video  (white  foreground  and 
blue  background).  The  command  that  is  highlighted 
when  the  mouse  button  is  released  is  invoked  and 
the  pull-down  menu  disappears.  If  the  mouse  cursor 
is  relocated  within  the  menu  bar  line  and  the  mouse 
button  released,  no  action  will  occur  and  the  pull¬ 
down  menu  will  disappear.  Similarly,  if  the  mouse 
cursor  is  dragged  outside  of  the  pull-down  menu 
window  and  released,  the  pull-down  menu  will 
disappear  and  no  command  will  be  chosen. 

b.2.5  Message  .Windows 

Informative  messages  are  about  the  current  system  action  requesting 
the  user  to  indicate  subsequent  actions  such  as  whether  the  currently  selected 
action  should  occur  or  be  cancelled.  The  options  available  to  the  user  are 
displayed  as  pushbuttons  and  one  of  the  pushbutton  must  contain  a  CANCEL 
option  that  permits  the  user  to  cancel  the  current  request  and  resume  the 
previous  activity. 


Location: 

Background  Color: 

IfiXtSolOP 
Graphics  Color: 
Border: 


A  separate  rectangular  window  that  is  located  in  the 
workspace  beneath  the  menu  bar. 

Blue. 

White. 

White. 

Double  line. 
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Characters: 


Message  displayed  in  sentence  format  with  initial 
C2ps  centered  in  window.  Pushbutton  labels  follow 
pushbutton  format 

User  Action:  The  mouse  is  used  to  move  the  mouse  cursor  to  the 

pushbutton  containing  the  desired  action  and 
depressed. 

8.2.6  Dialog  Windows 

Rectangular  windows  are  ones  in  which  the  user  enters  necessary 
information  in  pre-defined  fields  consisting  of  pushbuttons,  click  boxes,  check 
boxes,  text  entry  boxes,  labels,  and  scroll  bars. 

Location:  A  separate  rectangular  window  that  is  located  in  the 

workspace  beneath  the  menu  bar. 

Background  Color:  White. 

Text  Color:  Black. 

Graphics  Color:  Blue. 

Foreground  Color:  Blue. 

Double  line. 

Title  in  upper  case  centered  in  top  line  of  window. 

The  text  cursor  (cyan  background,  black  foreground) 
is  initially  placed  in  the  beginning  of  the  first  text  entry 
box  for  the  user  to  enter  the  indicated  information. 
When  the  entry  is  completed,  the  user  can  depress 
the  return  key  to  move  the  text  cursor  to  the  next  item 
in  the  sequence  or,  alternatively,  use  the  mouse  to 
move  the  mouse  pointer  to  the  desired  field  and  dick 
to  obtain  the  text  cursor  in  the  desired  location.  In 
addition,  the  tab  key  can  be  used  to  move  forward  to 
the  next  text  entry  field. 

B.2.7  Information  Windows 

informative  windows  are  ones  that  present  informative  messages  to 
the  user  about  current  system  activity. 


Border: 
Characters: 
User  Action: 
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Location: 


A  separate  rectangular  window  that  is  located  in  the 
workspace  beneath  the  menu  bar. 

Background  Color:  Blue. 


IfiXLCblSf: 
Graphics  Color: 

Bflgter: 

Characters: 

User  Action: 


White. 

White. 

Double  line. 

Message  displayed  in  sentence  format  with  initial 
caps  centered  in  window. 

Information  only,  no  user  response  permitted  in  the 
information  window  area  of  the  screen. 


B.2.8  Text  Entry  Screens. 

User  scrollable  windows  are  ones  in  which  the  user  can  enter 
textual/numerical  information  in  a  free-format.  A  scroll  bar  is  displayed  on  the 
right  side  of  the  window. 


Location: 

Background  Color: 
Text  Color: 
Graphics  Color: 

BPldgr: 

Characters: 

User  Action: 


A  separate  rectangular  window  that  is  located  in  the 
workspace  beneath  the  menu  bar. 

White. 

Black. 

Blue. 

Double  line. 

Title  in  upper  case;  contents  dependent  upon  user 
entries. 

The  rectangular  text  cursor  is  initially  placed  at  the 
upper  left  corner  of  the  window.  The  user  can  use 
the  mouse  or  arrow  keys  (right,  left,  up,  down,  home, 
page  up,  and  page  down)  to  position  the  text  cursor 
to  the  location  where  the  next  keyboard  entry  is  to  be 
placed.  All  key  strokes  are  inserted  at  the  current 
location  of  the  text  cursor.  If  the  entry  causes  the 
length  of  the  current  line  to  exceed  the  display  width, 
all  text  following  the  previous  delimiter  (space)  is 


moved  to  the  next  line.  The  depression  of  a  carriage 
return" moves  thetext  cursor  and  any  text  after  it  to  the 
next  line.  The  home  key  moves  the  text  cursor  to  first 
window  of  text;  the  end  key  moves  the  text  cursor  to 
1  the  last  window  containing  text. 
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A  list  selection  box  containsjjist  of  all  items  available  to- the  user  for 
the  current  function,  e.g.,  list  of  yjfes  for  the  rule  editor,  actions  for  the  action 
editor,  objects  for  the  object  editor,  etc.  It  requires  a  scroll  bar  on  the  right  side 
of  the  window  to  be  used  to  alter  the  viewing  area  of  the  window.  The  list  box 
window  may  obscure  the  previous  contents  of  the  screen  while  it  is  active. 


Graphic 

Border: 


A  separate  rectangular  window  that  is  located  in  the 
workspace  beneath  the  menu  bar. 
r:  White. 

Black. 

Blue. 

Double  line. 

Title  in  upper  case  in  center  of  top  line  of  window; 
pushbutton  labels  follow  pushbutton  format; 
remainder  dependent  upon  user  inputs. 

The  mouse  pointer  is  initially  located  on  the  first  item 
in  the  window.  The  mouse  is  used  to  move  the 
'  mouse  cursor  so  as  to  point  to  the  name  of  the  item  to 
be  selected.  The  currently  selected  item  is  shown  in 
reverse  video.  If  the  desired  item  is  not  currently 
displayed  within  the  window,  the  user  can  move  the 
mouse  cursor  to  the  red  triangles  located  at  either 
end  of  the  scroll  bar  and  then  depress  the  mouse 
button.  Each  click  on  the  red  triangle  will  display  the 
next  set  of  items  in  the  window,  if  the  user  clicks  on 
the  up  (down)  triangle  and  the  pointer  is  already 
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located  at  the  first  (last)  item,  the  contents  of  the 
screen  will  remain  identical.  Once  the  desired  item  is 
selected,  the  mouse  cursor  must  be  moved  to  the 
appropriate  pushbutton  to  invoke  the  desirnd  action 

B.2.10  List  Viewing  Box 

A  list  viewing  box  contains  a  list  of  all  defined  items  for  the  user  to 
view,  e.g.,  list  of  alphabetics  for  the  object  editor,  etc.  It  requires  a  scroll  bar  on 
the  right  side  of  the  window  to  be  used  to  alter  the  viewing  area  of  the  window. 
The  list  viewing  box  window  may  obscure  the  previous  contents  of  the  screen 
while  it  is  active. 


Location: 

Background  Color: 
Text-Color: 

Graph, ics  Color 

Border 

Characters: 


UseL  Action: 


A  separate  rectangular  window  that  is  located  in  the 
workspace  beneath  the  menu  bar. 

White. 

Black. 

Blue. 

Double  line. 

Title  in  upper  case  in  center  of  top  line  of  window; 
pushbutton  labels  follow  pushbutton  format; 
remainder  dependent  upon  user  inputs. 

The  mouse  pointer  is  initially  located  on  the  first  item 
in  the  window.  If  the  desired  item  is  not  currently 
displayed  within  the  window,  the  user  can  move  the 
mouse  cursor  to  the  red  triangles  located  at  either 
end  of  the  scroll  bar  and  then  depress  the  mouse 
button.  Each  click  on  the  red  triangle  will  display  the 
next  set  of  items  in  the  window.  If  the  user  clicks  on 
the  up  (down)  triangle  and  the  pointer  is  already 
located  at  the  first  (last)  item,  the  contents  of  the 
screen  will  remain  identical.  Once  the  viewing  of  the 
defined  items  is  complete,  the  mouse  cursor  must  be 
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moved  to  the  appropriate  pushbutton  to  invoke  the 
desired  action-” 


B.2.11  Push  Buttons 

Pushbuttons  perform  instantaneous  actions  as  described  by  the  text 
label  with  a  mouse  click  anywhere  within  the  button  area. 


Location:  A  separate-rectangular  window  that  is  located  in  the 

workspace  beneath  the  menu  bar. 

Background  Color:  Assumes  background  color  of  item  beneath. 


Text  Color: 
Graphics  Color: 
Barden 


User  Action: 


Red. 

Assumes  foreground  color  of  item  beneath. 
Rectangular  box  with  double  line  on  top  and  bottom; 
single  line  on  left  and  right.  It  is  sized  so  that  there 
are  at  least  two  leading  and  trailing  spaces  around 
the  pushbutton  legend. 

Upper  case  button  label  centered  in  box. 

The  mouse  is  used  to  move  the  mouse  cursor  so  that 
the  pointer  is  located  anywhere  within  the 
rectangular  area  and  then  a  mouse  button  is  clicked. 
Once  any  mouse  button  is  depressed,  the  button 
label  is  shown  in  reverse  video  (red  background  and 
white  foreground)  and  the  indicated  function 
immediately  invoked. 


B.2.12  Click  Boxes 

Click  boxes  are  used  to  specify  numeric  values.  It  requires  a  scroll 
bar  on  the  right  side  of  the  window  to  be  used  to  alter  the  numeric  value 
currently  displayed  in  the  window. 

Location:  Varies  but  always  within  a  dialog  window. 

Background  Color:  White. 


Graphics  Color: 

Border: 

Characters: 

User  Action: 


Blue. 

Rectangle  with  double  line  border. 

Title  in  upper  case  in  center  of  top  line  of  window;. 

The  user  can  modify  the  currently  displayed  value  by: 

1.  Moving  the  mouse  pointer  to  the  red 
triangle  located  above  the  box  to  increase 
the  number  shown  in  the  box  by  1  each 
time  a  mouse  button  is  depressed  or 

2.  Moving  the  mouse  pointer  to  the  red 
triangle  located  beneath  the  box  to 
decrease  the  number  shown  in  the  box  by 
1  each  time  a  mouse  button  is  depressed. 


B.2.13  Text  Entry  Boxes 

Text  entry  boxes  are  fields  where  textual  or  numerical  data  are 

entered. 


LQCatiQn: 

Varies  but  always  within  a  dialog  window. 

Background  Color:  white. 

Iaxt  Color: 

Black. 

Graphics  Color: 

Blue. 

Border: 

Rectangular  box  drawn  with  single  blue  line.  If  the 
entry  in  the  box  can  be  bigger  than  the  box  size,  a 
double  blue  line  is  placed  on  the  left  and  right  to 
indicate  that  the  user  can  scroll  right  and  left  within 
this  box. 

Characters: 

Label  with  initial  caps  terminated  with  a  colon  to  the 
left  of  the  box;  entries  in  box  are  based  upon  user 
actions. 

User  Action: 

The  rectangular  text  cursor  is  initially  placed  at  the 
left  side  of  the  box.  The  user  can  use  the  mouse  or 
arrow  keys  (right  and  left)  to  position  the  text  cursor  to 
the  location  where  the  next  keyboard  entry  is  to  be 
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placed.  AI!  keyboard  strokes  are  inserted  at  the 
current  location  of  the  text  cursor.  If  the  entry  causes 
the  length  of  the  current  line  to  exceed  the  display 
width,  either  of  the  following  will  occur: 

1 .  If  the  box  is  the  exact  size  of  the  permitted 
entry  (i.e.,  the  right  and  left  side  are  single 
lines),  a  beep  will  be  sounded  and  future 
keyboard  entries  (except  backspace  and 
delete)  will  be  ignored  until  a  non-text  key 
is  depressed  or 

2.  If  the  entry  can  be  larger  than  the  box  (i.e., 
the  right  and  left  sides  are  double  lines), 
the  text  will  be  scrolled  to  the  left  as 
additional  keys  are  depressed  until  the 
maximum  field  size  is  reached. 

The  left  and  right  arrow  keys  move  the  cursor  one 
space  in  the  indicated  direction  within  the  text  entry 
box.  The  home  key  moves  the  text  cursor  to  the  first 
character  in  the  box;  the  end  key  moves  the  text 
cursor  to  the  last  character  in  the  box. 


B.2.14  Scroll,  Bar 

Scroll  bars  are  used  to  change  which  part  of  a  list  of  items  (list 
window)  or  contents  of  a  file  (text  entry  window)  is  shown  the  window.  Double 
red  scroll  arrows  are  used  at  the  top  and  bottom  of  the  scroll  bar  rectangle  to 
indicate  the  direction  the  viewing  area  is  to  be  moved.  The  top  arrow  (A)  is 
used  to  scroll  up  one  line  at  a  time;  the  down  arrow  (▼)  is  used  to  scroll  down 
one  line  at  a  time.  The  second  up  arrow  (T)  is  used  to  scroll  up  one  page  at  a 
time;  likewise  the  top  down  arrow  (i)  is  used  to  scroll  down  one  page  at  a  time. 


Location: 


Rectangular  box  shown  on  right  side  of  text  entry  and 
list  boxes, 
r:  White. 
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lad  Cc  jar 
Graphics  Color: 
Border: 
Characters: 

User  Action: 


None. 

Blue. 

Double  line. 

Graphics  characters  of  T  and  A. 

The  user  uses  the  mouse  to  position  the  mouse 
cursor  at  the  desired  scroll  arrow  and  clicks  to  alter 
the  contents  of  the  window.  The  content  of  the 
window  is  moved  in  the  opposite  direction  from  the 
arrow.  For  example,  when  the  user  clicks  the  top 
scroll  arrow,  the  contents  moves  down,  bringing  the 
view  closer  to  the  top  of  the  list  or  document.  Each 
click  of  the  single  arrow  moves  the  window  contents 
one  line  in  the  chosen  direction;  each  click  of  the 
double  arrow  moves  the  window  contents  one  page 
in  the  chosen  direction.  Continuous  depression  of 
the  mouse  results  in  continuous  movement  in  the 
chosen  direction.  Once  the  top  or  bottom  of  the 
window  contents  is  reached,  depression  of  the  scroll 
arrows  in  that  direction  are  ignored. 


B.2.15  Labels 

A  label  is  an  alphanumeric  description  of  the  information  to  be 
entered  for  a  component  of  a  dialogue  window. 


Location;  Varies. 

Background  Color:  White. 


lest  C-PlQi: 
Graphics  Color: 
Border: 
Characters: 
User  Action: 


Blue. 

None. 

None. 

Initial  upper  case  and  terminated  with  a  colon. 
None. 
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B.2.16  Radio  Buttons  *“ 

Radio  Buttons  are  used  to  select  mutually  exclusive  options.  Tney  are 
displayed  as  small  circles  that  appear  to  the  left  of  the  option  label.  When 
selected,  a  smaller  black  dot  appears  within  the  circle.  Whenever  an  option  is 
selected,  the  previous  selection  is  deselected. 


Location: 
Background  Color: 

ISJSt  Color: 
Graphics  Color: 
Border: 
Characters: 

User  Action: 


Varies  but  always  within  a  dialog  window. 

White. 

Black. 

Black. 

Circle  with  single  line  border. 

Label  for  option  to  the  right  of  the  circle 

The  user  selects  the  desired  option  by  moving  the 

mouse  to  the  radio  button  next  to  the  desired  option. 


B.2.17  Check  Boxes 

Check  boxes  are  used  to  select  options  that  can  be  activiated 
simultaneously.  The  selection  of  an  option  will  not  deselect  previously  chosen 
options. 


Location: 
Background  Colon 

Text  Color: 
Graphics  Color: 

Boater: 

Characters: 

lisar.Actip.D: 


Varies  but  always  within  a  dialog  window. 

White. 

Black. 

Black. 

Rectangle  with  single  line  border. 

Label  for  option  to  the  right  of  the  box. 

The  user  moves  the  mouse  cursor  within  the  desired 
box  and  clicks. 


B.2.18  Mouse  Cursor 

The  mouse  cursor  is  a  pointing  device  used  to  select  commands  from 
menus,  to  control  cursor  movement,  and  to  manage  file  scrolling. 
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Location: 


Varies. 

Assumes  background  color  of  object  beneath. 

None. 

Assumes  foreground  color  of  objeci  beneath. 

None. 

Arrow  (*). 

The  user  moves  the  mouse  cursor  to  the  desired 
location  by  moving  the  mouse  in  the  desired 
direction.  Every  mouse  movement  moves  the  mouse 
cursor  in  exactly  the  same  way.  The  following  mouse 
actions  can  be  performed: 

•  Clicking  —  positioning  the  mouse  cursor 
with  the  mouse,  briefly  pressing  and 


releasing  the  mouse  button  without  moving 


the  mouse. 


•  Pressing  —  positioning  the  mouse  cursor 
with  the  mouse,  holding  down  the  mouse 
button  without  moving  the  mouse. 

•  Dragging  —  positioning  the  mouse  cursor 
with  the  mouse,  holding  down  the  mouse 
button,  moving  the  mouse  to  a  new 
position,  then  releasing  the  button 
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The  text  cursor  indicates  where  next  keyboard  stroke  will  be  entered. 


Location: 


Border: 


Varies, 
r:  Cyan. 

Black. 

Assumes  foreground  color  of  object  beneath. 
None. 

Rectangle  the  size  of  a  single  character  (I). 
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